[Seaside] How do you handle constraints on persisted collections?
Smalltalk at JGFoster.net
Tue May 19 02:27:28 UTC 2009
In my experience this sort of constraint is somewhat rare and I don't
feel like it needs a generalized solution. That is, it does make sense
to require all user IDs to be unique, but multiple users with the same
name might be okay (Sr./Jr.). In particular, you should design things
so that it is legal for two people to have the same SSN, driver's
license, passport number, etc.
Most values that need to be unique can be assigned by the system and
never changed. A user ID is special in that we often want to allow the
user to propose an ID. For this, I'd probably use a Dictionary as the
collection and then either forbid changing the user ID or provide a
special API for changing the user ID. You could even leave the ID off
the User (as an instance variable) and use #'keyAtValue:' (or is it
#'keyWithValue:' or #'keyForValue:'?) to get the ID from the
collection. Then you would be guaranteed that only one user would have
a particular ID (though you would have to do a bit of work to ensure
that a user had exactly one ID).
On May 18, 2009, at 4:50 PM, Pat Maddox wrote:
> I'm trying to make the leap from RDBMS/ORM thinking to pure objects,
> and am running into some problems. The first is how to handle
> constraints on collections, when the objects inside of that collection
> are mutable. Quick example, ensuring that only one user exists with a
> certain username. It's trivial to check that a username is available
> before adding the user to a UserRepository. If a user can update his
> own username though, it'll bypass any check on the UserRepository and
> invalidate that constraint. A couple options...
> 1. Have a ChangeUsername command that reserves that username in the
> repo, tells the user object to change its username, and then tells the
> repo to free the original username
> 2. When user username: is called, publish a UsernameChanged event that
> the repository subscribes to. The repo can choose to reject the
> change if it would violate the repo's constraints.
> The first is just a bit ugly and procedural. The second requires the
> User object to publish events whenever something happens - which is
> easy to forget to do, or you're left with determining which method
> calls warrant the publishing of events. Also you'd have to roll back
> the change if the event is rejected.
> You could handle that stuff by writing some framework code to manage
> the tedious stuff...I don't love either approach though. How do you
> guys tackle this sort of problem?
> seaside mailing list
> seaside at lists.squeakfoundation.org
More information about the seaside