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

Michael Forster mike at sharedlogic.ca
Tue May 19 22:22:52 UTC 2009

On Tue, May 19, 2009 at 5:05 PM, Boris Popov <boris at deepcovelabs.com> wrote:
> Although, if two users are updating their usernames in separate transactions (say, in GemStone), this would do nothing to prevent both of them from succeeding, thus, this type of constraint checking really only applies when adding users to a collection which would stop this from happening by virtue of a commit conflict, no?
> -Boris

Yes, exactly.  I saw no indication of the UserRepository being
anything but a simple collection, so I deliberately focused on the
implementation of the constraint expression and how it might be
applied to a collection.

And thank you for raising this point. It highlights the numerous and
terribly nasty details that we forget when we dump our SQL DMBSs in a
fit of ORM frustration, start Googling for an OODBMS, and then, in
dismay, entertain brewing up our own home-grown solution. That way
lies madness.  I know.  I have used various DBMSs for twenty years,
including SQL-based ones, OO-based ones, and _real_ RDBMSs (Dataphor
and Rel).  I've also written my own partial implementations to better
understand the problems.  It's one thing to eschew the use of the
Relational Model; it's another to do so oblivious to the implications.


More information about the seaside mailing list