[Seaside] How do you handle constraints on persisted collections?

[Michael Forster]

On Wed, May 20, 2009 at 8:56 AM, Marcin Tustin <mm3 at zepler.net> wrote:
> I think we're talking slightly at cross-purposes: I'm suggesting that
> code to support things like constraints would often have to be written
> anyway, as part of creating tests to verify that the code works.

Absolutely, if you're writing constraints procedurally.  And if you're
writing procedural constaints in Smalltalk you have a significant
advantage in unit testing over SQL triggers.  However, if you're using
declarative SQL constraints (primary key, foreign key/references, row
check, table check, and etc.) then you do not need to write any tests.
 The point of declarative constraints is that the DBMS has already
been tested with regard to enforcing them.  Better yet, a correctly
implemented SQL DBMS won't allow you to declare a constraint on
existing data that would violate the former.  Try that with procedural
constraints.


> For very simple systems, this will be very simple, and it may be
> easier to use a DBMS. For moderately complex systems, this might be
> complex enough that you might not save much time (if any) with a
> database. For very complex systems, it's often best to have a separate
> element that can check the sanity of your data (the database).

Other way around.  With simple systems (and we should define
"simple"), you might be less likely to need many SQL DBMS features, so
you can save the cost of ORM.  With more complex systems, you are more
likely to need them and the cost of ORM could very well be far less
than the cost of coding some very tricky constraints, optimized
queries, etc.

Mike