Re: [Modeling-users] one model, multiple database instances

[Sebastien B. <sbi...@us...>]

Mario Ruggier <ma...@ru...> wrote:
[...]
>=20
> >   The real problem here is that you're gonna have objects corresponding
> >   different entities, all named Document but living in different
> >   database. Say you have database DB1 and DB2, you suggest that we can
> >   have at runtime objects doc1 and doc2, resp. being object for entities
> >   Document in DB1 and Document in DB2.
> >
> > Now you'll see the real problem if you realize that each object is
> > uniquely identified by its GlobalID.  And a GlobalID is the combination
> > od an entity name and its PK value(s).  If obj1 and obj2 and the same
> > PK, then they will get the same gID.
>=20
> But, is this simply a matter of changing the algorithm of how a GID is
> calculated?
> What if you throw in for example the database name as part of that=20
> calculation?
> Then, two objects may have the same entity name, same model name, same PK
> even... but if they come from a different db, there will not be any
> ambiguity... Note that this should also allow for the possibility to have
> the same object from the same database but in two distinct EditingContexts
> (not one that inherits from the other), to be correctly identified by the
> framework as the same object.

If by "database name" you mean adaptor name + db name + user name
(Oracle for example can handle two db with the same name for two
different users), then yes, in theory this works.

>=20
> > The consequences are, as expected,
> > devastative: snapshots are all mixed up, faults will pick up from the db
> > cache some data that in fact belongs to another database, etc...
> >
> >   In brief: your suggestion requires that the entities' names live in a
> >   separate namespace, or put differently, that an entity is identified =
by
> >   its name and its model's name.
>=20
> Yes, entities' names should be in a different namespace... but, I would go
> even further, and suggest also that models live in a separate namespace,
> defined by the database instance. Thus, you can instantiate the same model
> **exactly**, but bound to different databases.

Again, in this case, yes, this would work.  But this requires a lot of
changes.  And back to reality, I believe that:

1. Any app. that would require/benefit from such a feature can anyhow
   solve the problem differently and without much trouble,

2. this would add either some heavy changes in the API or some sort of
   "implicit" knowledges about the EC e.g. for some operations. For
   example: would we require that ec.fetch() specifies the exact Entity
   object (or an equivalent string, with the whole conn.dicyt (possibly
   hashed)?  Or would we rather consider by default the model to which
   the EC is bound, making the portion of code::

        ec.fetch('Person')

   fuzzy about which Entity it fetches?=20

> [...] I want to understand better if the idea makes any sense, if
> having such a way of initialising an EC brings other advantages or
> disadvantages, and how difficult it is to modify the framework so
> drastically.
>=20
> I cannot appreciate how much work such a thing could be, but from what
> you say above I suspect it may be less than I thought ;)
>=20
> In any case, I think it would be too early to add this as a TODO item
> as yet, as further poking and contemplation is probably a good
> idea. Anyone else following this issue have an opinion?

You're right, that's way too early!...  As you probably already guessed,
the more I'm thinking about such an extension, the less I like it.  The
concepts is simple, but the consequences, esp. on the API, are not
desirable at all.  I believe that asking more than an Entity to be
supplied to e.g. ec.fetch() is not a very good idea, and I do not like
the idea of adding the level of implicit described above in statements
like ec.fetch().  Makes sense?

-- S=E9bastien.