Voyage: Unique vs Multiple repo

Hi,

I have three questions regarding these two options.
As a matter of analogy to what I know, for me a Voyage repo is like a
database and collections like tables in relational db world.

So what is the argument to use multiple repo for an application domain?

When using two repo A and B, is it ok to have instances saved in A with
attributes saved in B?
When fetching instances from A, will these instances get their
attributes saved in B right?

Thanks

Hilaire

--
Dr. Geo
http://drgeo.eu

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


Le 20/02/2017 à 19:26, Hilaire a écrit :
> When using two repo A and B, is it ok to have instances saved in A with
> attributes saved in B?
> When fetching instances from A, will these instances get their
> attributes saved in B right?

--
Dr. Geo
http://drgeo.eu

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

Thanks Esteban for your detailed answer.

Le 23/02/2017 à 13:23, Esteban Lorenzano a écrit :

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

Thanks to clarify, it helps to understand Voyage's boundaries.

> - if one object can be on repo1 and repo2, then probably you need to join those repositories

This put me back at my initial questioning: is there any reason to have
several repositories for one application domain?

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

Indeed, I was thinking about storing reference.

Thanks

Hilaire

--
Dr. Geo
http://drgeo.eu