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

[Mario R. <ma...@ru...>]

Sorry about the delay in getting back on this. Also, as this discussion=20=

is on a very low priority enhancement, and one that S=E9bastien clearly=20=

does not like, I do not want to belabor the issue too much. But for the=20=

sake of correctness, I will just add a few comments that I hope are=20
relevant.

On Aug 30, 2004, at 10:39 PM, Sebastien Bigaret wrote:
> Mario Ruggier <ma...@ru...> wrote:
> [...]
>>
>>>   The real problem here is that you're gonna have objects=20
>>> corresponding
>>>   different entities, all named Document but living in different
>>>   database. Say you have database DB1 and DB2, you suggest that we=20=

>>> 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=20
>>> 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
>> calculated?
>> What if you throw in for example the database name as part of that
>> calculation?
>> Then, two objects may have the same entity name, same model name,=20
>> 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=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 identified by=20=

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

I guess "database name" will have to be equivalent to the conn=20
dictionary, and mapped down to a single database instance, however that=20=

might be handled by the underlying db.


>>> The consequences are, as expected,
>>> devastative: snapshots are all mixed up, faults will pick up from=20
>>> the db
>>> cache some data that in fact belongs to another database, etc...
>>>
>>>   In brief: your suggestion requires that the entities' names live=20=

>>> in a
>>>   separate namespace, or put differently, that an entity is=20
>>> identified by
>>>   its name and its model's name.
>>
>> Yes, entities' names should be in a different namespace... but, I=20
>> would go
>> even further, and suggest also that models live in a separate=20
>> namespace,
>> defined by the database instance. Thus, you can instantiate the same=20=

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

I can appreciate that the framework change may not be feasible at all,=20=

and that workarounds are available. My concern though is primarily to=20
simplify and improve how the framework can be used. It is (kind of ;)=20
like saying that there is no need to make a piece of code clearer=20
because it works...


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

I am not sure I understand your first point here. I was assuming=20
something along the lines of the second one, that is:
- an EC instance *must* be initialised with a Model instance, and a=20
ConnDict
- each object in the EC corresponds to a Type (from the model) and a=20
table row in the db identified by the conndict
- if a second EC is initialiased in the same way, then if the same=20
object is loaded in either of these two ECs, it will have the same gid.
- nested ECs must assume the same model and conndict of the parent EC

Thus, except for the difference in EC initialisation, I do not see why=20=

the API should change at all... at least the exposed API, as internally=20=

there may well be major issues that I am not even considering.


>> [...] 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.
>>
>> 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 ;)
>>
>> 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=20
> 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?

Again, I do not get this point, i.e. why do you need to specify more=20
than the Entity to ec.fetch() ? The ec instance itself knows what the=20
context of the fetch is, and that is the model instance plus the=20
conndict it was initialised with. The fetch interface should not change=20=

at all.... but, I think I may be missing something here!

> -- S=E9bastien.


Cheers, mario