Problem with criteria

[Bill Larman]

If I create an editable root object from a table with a Primary Key
column (PK) and a Timestamp column (TS) , then I get one criteria
object created that includes the PK and TS.

The DataPortal_Fetch uses this criteria object and passes both the PK
and TS to the stored procedure.
I think that a seperate criteria should be automatically created for
the Fetch that only includes the PK as the TS has no meaning before
the object is fetched.
I can manually create this criteria, but as I have about 25 object to
create thsi would be a bit tedious.

Also if this second criteria was created automatically I could use it
for the Delete where typically I am not worried about the timestamp
and just want to delete using the PK. (Maybe this could be the default
working or a new option)

[Andrés]

Well, that makes sense for fetch, but I'm not sure about delete...
I'm not a timestamp user, so bear with me. What if you're about to delete a record because it's "description" field says "Test", but other user updated it to be an actual "good" record instead of deleting and creating a new record. I would believe that the fact that other user updated the record after you got it and before you decided to delete it should block you from doing so to follow the timestamp pattern, right?

--
Andrés

[Bill Larman]

Sometimes I need to check whether the data has changed before deleting
and sometimes I don't care and just want it deleted.
So I'm happy that if the extra criteria object was automatically
created then I could use this for the deletes when I wanted.
It would be nice to have this as a new option at the Object Info level
- e.g. in the 03 Section 'Criteria for delete' to choose from a
dropdown of the 2 criteria objects.

Do you hand code your stored procedures as I have noticed that if
timestamps are not used then the stored procedures generated just do
updates and deletes based on the primary key and don't check that
anything has been changed by another user.

I have another problem with the timestamp and the generated stored
procedures but I will start a new thread.

On Oct 8, 10:01 pm, "Andrés" <xal1...@gmail.com> wrote:
> Well, that makes sense for fetch, but I'm not sure about delete...
> I'm not a timestamp user, so bear with me. What if you're about to delete a
> record because it's "description" field says "Test", but other user updated
> it to be an actual "good" record instead of deleting and creating a new
> record. I would believe that the fact that other user updated the record
> after you got it and before you decided to delete it should block you from
> doing so to follow the timestamp pattern, right?
>

> On 10/8/07, Bill Larman <bill_lar...@hotmail.com> wrote:
>
>
>
>
>
>
>
> > If I create an editable root object from a table with a Primary Key
> > column (PK) and a Timestamp column (TS) , then I get one criteria
> > object created that includes the PK and TS.
>
> > The DataPortal_Fetch uses this criteria object and passes both the PK
> > and TS to the stored procedure.
> > I think that a seperate criteria should be automatically created for
> > the Fetch that only includes the PK as the TS has no meaning before
> > the object is fetched.
> > I can manually create this criteria, but as I have about 25 object to
> > create thsi would be a bit tedious.
>
> > Also if this second criteria was created automatically I could use it
> > for the Delete where typically I am not worried about the timestamp
> > and just want to delete using the PK. (Maybe this could be the default
> > working or a new option)
>
> --

> Andrés- Hide quoted text -
>
> - Show quoted text -