Re: one model, multiple database instances

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 <[email protected]> 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



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php