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

James Foster Smalltalk at JGFoster.net
Tue May 19 02:27:28 UTC 2009


Pat,

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).

James

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?
>
> Pat
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>



More information about the seaside mailing list