Voyage: Unique vs Multiple repos

> Hi,
>
> It looks like Voyage will duplicate in repo A the instance saved in repo
> B in the first place. These two instances of an identical object will
> have different ID.
>
> The following script shows this behaviour:
>
> | orga repo1 repo2|
> repo1 := VOMongoRepository host: ‘localhost’ database: ‘test1’.
> repo2 := VOMongoRepository host: ‘localhost’ database: ‘test2’.
> orga := ‘Pharo’ -> 13.
> repo1 save: orga.
> repo2 save: (‘Hilaire’ -> orga).
>
> repo2 selectAll: Association.
>
> => an OrderedCollection(‘Hilaire’->’Pharo’->13 ‘Pharo’->13)
>
> How do you guys avoid such duplication of identical instances in two
> different repo?
>
> Let’s say you want to have in one repository a collection of reference
> data, but these data are used by other instanced saved in another repo.
> Then from time to time this data may need to be edited, copy of these
> data will then be obsolete.
>
> Thanks
>
> Hilaire


Hi Hilaire,

Voyage will not handle that kind of problem. Voyage will not know anything about instance A being saved in repo1 AND repo2.
Also, I do not think it should

I think you have a design problem if you want something like that to work…
let’s explore the consequence of implementing something that would automatise that:

– you could have a “meta-cache” in the image with the objects in all repos, then on save you first check if is there and to which repository it belongs
– but that will not solve the problem, because object could be in repoX but not at the moment in the image, so you need to go to the repository to verify if is already there
– and that, for each repository you will want to handle.

So, how to handle this? Not to having the problem

– if one object can be on repo1 and repo2, then probably you need to join those repositories
– if that duplicated value is an enum type (like enum objects), then you do not want to persist that: what you do is to persist a reference, then on materialisation you refer to your enum (I do that a lot, in some apps)\
– if you want to have for example, your list of organisations in one repository and then one repository for each organisation, you can still apply same pattern as before, but instead enums you persist a reference to your organisation and then on materialisation you can repoint to it.
For example, this lates approach would be defined something like this:

We have objects Organisation, User (with organisation as attribute).

in repo1 you want to keep all organisations
in repo2 you want all users

then you do something like this:

User class>>mongoOrganisation
<voyageDescription>

^ VOToOneDescription new
attributeName: ‘organisation’;
accessor: (MAPluggableAccessor
read: [ :user | repo1 keyOf: user organisation ]
write: [ :user :value | user organisation: (repo1 selectOne: Organisation where: { ‘_id’ -> value } asDictionary ) ] );
yourself

Something like that.

Esteban

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: