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

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

        Hi Mario and all,

Mario Ruggier <ma...@ru...> wrote:
[...]
> Anyhow, w.r.t. the initial argument of this thread, what you suggest, i.e=
. to
> dynamically create as many models as you need but with class names done w=
ith
> Table_ID, seems rather opaque and awkward to me...

  Well, awkward I don't know, probably a matter of taste! but anyhow it
  was not my suggestion, it was the initial requirement: Delio wants a
  database per user. Each of these database needs to be uniquely defiend
  within the server, and I think that naming each of them after the
  user/login name is quite straightforward ;)

Now, since all entities live in a single namespace, then they need to be
uniquely defined as well --that's why they are also named after the
user's name, the only reason, but also a very strong one.

> How big of shaker would it be to give the EditingContext control over
> which database it is working with? Even if it is the same model and
> entity namespace in memory, why not allow the EditingContext to
> specify its connection dictionary? i.e.
>=20
> ec1 =3D EditingContext(connDict1)
> ec2 =3D EditingContext(connDict2)
>=20
> I guess EditingContext could also grow an optional model
> parameter... for when the system will support more than the
> defaultModel.
>=20
> For EditingContexts that inherit from another, they would need to
> exist in the same db context, so they will be obliged to use their
> parent's connection dictionary...
>=20

NB: I'll answer here as if you suggested that we could have entities
    sharing the same name in different model having different connection
    dict; this is equivalent to what you say if we consider that a model
    and its connection dict. *cannot* be separated --later in the post
    I'll explain why they cannot be decorrelated.


  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=20
  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.  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.  Alas, the whole framework has been
  coded with the idea of unique, distinct entities names, so while this
  is possible, and while this could be added as a TODO item, this
  definitely won't come up as a priority item for long :/

> In fact this reminds me of a remark some months ago, about extracting
> the connection dictionary out of the model altogether, where I had
> claimed, without really substantiating it, that it does not seem that
> that is where the connection dictionary belongs... ;)

I strongly disagree here: the connection dictionary does belong to the
model: this is entity-relationship modeling, entities describe classes
stored in databases.  Or, if you prefer: as soon as an object is
fetched, the model is tightly bound to its connection dictionary: its
connection dictionary becomes a read-only attribute.  So, even if the
values for the conn.dict. can be specified elsewhere (as you suggested,
and as it was implemented w/ MDL_DB_CONNECTIONS_CFG since), it is a
constituent part of the model.


-- S=E9bastien.