Hi Esteban,
What you have described is quite common and there are a variety of ways of
designing this sort of object model. If you were dealing with a relational
database, then you would have a Group table, a Member table, and a Membership
table. The Membership table would have one row for each member/group pair and
the member ID and group ID would be the primary columns (perhaps with other
things like date joined, date expired, etc.). With an index on the member ID
and group ID, one could quickly find all the groups for a member and all the
members for a group, and each piece of data would exist in only one place
("normalized"). One could take a similar approach with objects, having three
collections containing Groups, Members, and Memberships respectively. You could
have an accessor in Group that returned members based on a select from the
Memberships collection and an accessor in Member that returned groups based on
a select from the Memberships collection.
Alternatively, if you wanted to avoid the #'select:' call in one or both
lookups, you can cache the respective subcollections in Group and/or Member and
drop the Memberships collection. If you cache in only one place (e.g., each
Group has a collection of Members), then you can add a method in Member that
does a #'select:' of Groups where a Group has the Member. If you cache in both
places then your getters/setters in each can update the other (with the
understanding that you are duplicating data to get performance efficiency).
Again, this problem is very common. Consider students in classes, persons with
addresses, persons with hobbies, etc. Your choices are basically (1) three
collections, no duplicates, select for both queries; (2) two collections, no
duplicates, cache for one query, select for the other query; and (3) two
collections, caches for each query. Which is preferable depends on your typical
sizes and lookup patterns. If performance is not an issue, then start with
whatever is simplest for you to code. I lean toward the three collections with
the lookup penalty (GemStone's ability to index collections makes this approach
very efficient), but if most of your lookups are from one side or the other and
scanning the full collection is slow, then cache in one or both places.
If you have a composite, the analysis is similar since Smalltalk does not
require static typing of variables. You just need to take care that your
accessors can give back the expected objects.
James
On Aug 29, 2013, at 6:12 PM, Esteban A. Maringolo <emaring...@gmail.com> wrote:
> Hi all,
>
> Let's say I have a class Group and a class Member.
>
> aGroup has many members.
> and aMember can belong to many groups.
>
> What is the "proper" voyageDescription for those one to many relations?
>
> Should I do something extra?
>
> Everytime I add a member to the group, both the member and the group
> get their references updated.
> Now when I add a member to a group and save it, I also save the
> member. Is there another way to avoid this?
>
> Any recommended practice for this?
>
> Next level question: What if it gets composite? it is... a Group has
> other Groups as members :)
>
>
> Regards!
>
> Esteban A. Maringolo
>
>
