On 02/06/2009, at 8:08 PM, Andrus Adamchik wrote:
On Jun 2, 2009, at 12:29 PM, Aristedes Maniatis wrote:
1. Because the second most commonly used implementation will be:
* boolean NOT NULL field called 'isDeleted'
Could this alternative implementation be one of the 'out of the
box' choices? For us, we'd want that choice per table since some
tables we actually do delete (since we don't care about keeping
historical data). For Cayenne, the ability to do this without too
much code would be very useful and a strong 'selling point' for the
framework.
(BTW we have another area where we could provide a sensible default
- the auto increment version column.)
What I would like to avoid is implicit invisible mappings forcing
user into Cayenne table/column naming conventions. The ability to
work on top of an (almost) arbitrary schema is a big deal in the
database world. Cayenne never had any such conventions (ok, except
for AUTO_PK_TABLE), and this was also a strong usability point.
Fortunately we have the Modeler, so we can achieve the best of both
worlds. The modeler can create a needed column and a qualifier if an
entity is marked as "soft delete". The user can stick with those, or
go and edit the names.
For sure. I think Andrey wants to implement a generic hook so that the
entire implementation of what 'delete' means can be replaced by an
alternate strategy almost like specifying a lifecycle listener. That
sounds really complex for a user to implement, but some baked-in
strategies would be useful. You would still get to choose which column
represents the concept of 'deleted', just as you currently choose
which column is the inheritance discriminator in the superclass
dbEntity.
Ari
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
