Re: one model, multiple database instances

On Aug 24, 2004, at 10:55 PM, Sebastien Bigaret wrote:
>
>         Hi Mario and all,
>
> Mario Ruggier <[email protected]> wrote:

[...]

Thanks for the detailed reply! It helps me understand better what's=20
involved.... further comments below.

>> 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.
>>
>> ec1 =3D EditingContext(connDict1)
>> ec2 =3D EditingContext(connDict2)
>>
>> I guess EditingContext could also grow an optional model
>> parameter... for when the system will support more than the
>> defaultModel.
>>
>> 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...
>>
>
> NB: I'll answer here as if you suggested that we could have entities
>     sharing the same name in different model having different=20
> connection
>     dict; this is equivalent to what you say if we consider that a=20
> model
>     and its connection dict. *cannot* be separated --later in the post
>     I'll explain why they cannot be decorrelated.

Yes, exactly... a model instance cannot change its connection=20
dictionary!
I think what I was saying, but without the intimate knowledge of the=20
internals of the framework to be so precise, is for a model "class" to=20=

be instantiated at EditingContext() time, as opposed to model load time=20=

(this will give you the model "class"... ).

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

But, is this simply a matter of changing the algorithm of how a GID is=20=

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=20=

PK even... but if they come from a different db, there will not be any=20=

ambiguity... Note that this should also allow for the possibility to=20
have the same object from the same database but in two distinct=20
EditingContexts (not one that inherits from the other), to be correctly=20=

identified by the framework as the same object.

> The consequences are, as expected,
> devastative: snapshots are all mixed up, faults will pick up from the=20=

> 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=20=

> by
>   its name and its model's name.

Yes, entities' names should be in a different namespace... but, I would=20=

go even further, and suggest also that models live in a separate=20
namespace, defined by the database instance. Thus, you can instantiate=20=

the same model **exactly**, but bound to different databases.

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

Certainly, and this is exactly the the kind of feedback I'm looking for=20=

when I put out this suggestion... I want to understand better if the=20
idea makes any sense, if having such a way of initialising an EC brings=20=

other advantages or disadvantages, and how difficult it is to modify=20
the framework so drastically.

I cannot appreciate how much work such a thing could be, but from what=20=

you say above I suspect it may be less than I thought ;)

In any case, I think it would be too early to add this as a TODO item=20
as yet, as further poking and contemplation is probably a good idea.=20
Anyone else following this issue have an opinion?

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

Yes, this emphasises what what said above.... once an object is=20
fetched, the model is bound to its conn dictionary... i.e to the=20
database. So, if the db can be specified at EC() creation time, then=20
(conceptually, at least ;-\ ) there need not be any GID clashing=20
between objects coming form the same model and the same entity...

> -- S=E9bastien.


Thanks again!

mario





-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285