DatabaseAccess settings for ValueProperty

[Tiago Freitas Leal]

Hi Andrés,

The new CSLA.NET 4.0 boosted my interest in CslaGen. This also means
I'm having a lot of questions due to the lack of documentation.

The question for today concerns DatabaseAccess settings for
ValueProperty. There are 5 options that refer to a given property
being read or written to the database columns. They have no relation
to the property being used as a parameter of a stored procedure (you
need to pass the object ID in order to fetch the object but you really
don't need or even want to receive the object ID as part of our select
statement). So this setting only affects the Create, Read, Update and
not Delete operation since the later doesn't exchange (gets or sets)
data with database columns.

Testing was inconclusive In spite of setting the ID property to
CreateOnly, it did show up in in the Get stored procedure as the first
item of the SELECT statement. Obviously this isn't what CreateOnly
should mean...

So I came up with this scenario:
ReadWrite CRU
ReadOnly -R-
WriteOnly C-U
UpdateOnly --U
CreateOnly C--

Note - The capital letters signal the CRUD operations where the
property will be part.

Is this correct?

[Tiago Freitas Leal]

Hi all

> Testing was inconclusive  In spite of setting the ID property to
> CreateOnly, it did show up in in the Get stored procedure as the first
> item of the SELECT statement. Obviously this isn't what CreateOnly
> should mean...
>
> So I came up with this scenario:
> ReadWrite  CRU
> ReadOnly   -R-
> WriteOnly  C-U
> UpdateOnly --U
> CreateOnly C--
>
> Note - The capital letters signal the CRUD operations where the
> property will be part.

It turns out that generated code and stored procedures match. The
table below is the correct one:

ReadWrite  CRU
ReadOnly   -R-
WriteOnly  C-U

UpdateOnly -RU
CreateOnly CR-

So UpdateOnly means UpdateReadOnly and CreateOnly means
CreateReadOnly.

To test it beyond reasonable doubt, you must use properties as normal
as they could be
- not part of any Criteria
- PrimaryKey set to Default
- for child objects, the properties can't be part of 04. Child Object
Options - Parent properties.

Don't misunderstand me. You can use DatabaseAccess on every situation.
When the property is in one of the above special situations, it might
seem the option is behaving properly.

[Andrés Villanueva]

Hi Tiago!

There's one other property to take into account here: PrimaryKey.
If that property is set to either DBProvidedPK or UserProvidedPK, it the templates disregard the setting for DataAccess.
The reasoning is that depending on the type of primary key you choose, it needs to be readonly, or createonly, but also needs to be used as a param for update and delete. So, in short, properties that are reflect the identity of the object need to have a special treatment.

Cheers!

--
http://groups.google.com/group/CslaGenerator
Post to: CslaGe...@googlegroups.com
Unsuscribe: CslaGenerato...@googlegroups.com
Join us on #CslaGenerator @ irc.freenode.net

--
Andrés