Hi, I have to maintain a collection of ULUser(s). How can I make sure that I can't register two users with the same #login (instance attribute)? Is MagmaSet the solution to the problem?
Best regards, cdan.
Hi Dan, if you have only a few users (less than 500) and the collection doesn't change much, you may want to use a standard Smalltalk collection (like a Set).
My guess is you want to display an error if someone tries to add a new ULUser with the same #login as another. So using a Set or MagmaSet might not report that a duplicate was attempting to be added, just quietly ignore the add, leaving the registering user thinking they were successful.
Perhaps you want to just as easily perform a #where: (or #select:) query in your application to see if some ULUser with that #login already exists and then signal a UserError..?
Regards, Chris
On 8/8/07, Dan Corneanu cdan@savatech.ro wrote:
Hi, I have to maintain a collection of ULUser(s). How can I make sure that I can't register two users with the same #login (instance attribute)? Is MagmaSet the solution to the problem?
Best regards, cdan. _______________________________________________ Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
Hi,
My guess is you want to display an error if someone tries to add a new ULUser with the same #login as another. So using a Set or MagmaSet might not report that a duplicate was attempting to be added, just quietly ignore the add, leaving the registering user thinking they were successful.
This is not correct: MagmaSet>>#add: will signal a MagmaDuplicateObjectInCollection notification when an attempt to add duplicate object.
Try: [ users add: aUser ] on: MagmaDuplicateObjectInCollection do: [ self inform: 'user already exists ].
Cheers
Brent
This is not correct: MagmaSet>>#add: will signal a MagmaDuplicateObjectInCollection notification when an attempt to add duplicate object.
Ok, yes. But do you know why we made it inconsistent from a standard Set?
|o| o := Object new. Set new add: o; add: o; size "1"
Cheers, Chris
Hi,
Chris Muller wrote:
Hi Dan, if you have only a few users (less than 500) and the collection doesn't change much, you may want to use a standard Smalltalk collection (like a Set).
My guess is you want to display an error if someone tries to add a new ULUser with the same #login as another. So using a Set or MagmaSet might not report that a duplicate was attempting to be added, just quietly ignore the add, leaving the registering user thinking they were successful.
Doesn't MagmaSet signal a MagmaDuplicateObjectInCollection if one tries to add a duplicate object (#validateCanAdd:)?
Perhaps you want to just as easily perform a #where: (or #select:) query in your application to see if some ULUser with that #login already exists and then signal a UserError..?
Ok, registering a user will not be a very frequent operation, but I can think of a scenario in which between performing a #where: and actually adding the new user, another user has managed to register with the same login and commit the changes to the DB. Is there a way to make the #where: followed by #add: execute as a single atomic operation? or should I find a way to implement a synchronization mechanism (maybe based on locking, if this is possible in maven)?
Best regards, cdan.
Ok, registering a user will not be a very frequent operation, but I can think of a scenario in which between performing a #where: and actually adding the new user, another user has managed to register with the same login and commit the changes to the DB. Is there a way to make the #where: followed by #add: execute as a single atomic operation? or should I find a way to implement a synchronization mechanism (maybe based on locking, if this is possible in maven)?
If you use a standard Smalltalk collection, you'll get a commit conflict. Since MagmaCollections are reduced-conflict, you'll need to do something extra. For example, you could "reserve" the login by adding it to a Smalltalk Set in a pre-commit. If successful, add it to the MagmaSet and remove it from the reserve-Set in a post-commit.
There are probably other ways too.
Best regards, cdan.
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
magma@lists.squeakfoundation.org