[Seaside] How do you handle constraints on persisted collections?
mm3 at zepler.net
Wed May 20 13:56:54 UTC 2009
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.
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 features may or may not be replicated - querying is comething in
particular that can get painful in large systems.
On Wed, May 20, 2009 at 2:14 PM, Michael Forster <mike at sharedlogic.ca> wrote:
> On Wed, May 20, 2009 at 7:56 AM, Marcin Tustin <mm3 at zepler.net> wrote:
>> Surely much of this code would need to be written anyway, in order to
>> unit test, and verify that the system is mapping properly with the
> I didn't say that the ORM code is small or trivial. I suggested that a
> point may be reached where it is smaller and/or simpler than
> implementing constraints (and many other DBMS features) by hand. For
> comparison, implementing constraints procedurally via SQL triggers is
> far more verbose, time-consuming, and dangerous than a one-line SQL
> key or check declaration. That most SQL DBMSs do not provide the full
> range of constraint declarations prescribed by the Relational Model is
> a short-coming of the former, not the latter.
> In my experience, your conjecture bears out in small systems where the
> number and complexity of constraints required is low. However, I have
> seen very few such systems stay that way for long. Customers throw
> all kinds of business rules at you.
> seaside mailing list
> seaside at lists.squeakfoundation.org
More information about the seaside