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

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

On Aug 13, 2004, at 12:27 AM, Sebastien Bigaret wrote:
> Mario Ruggier wrote:
> [...]
>> Another situation in which this could apply is for migrating from one
>> db+model to another... a little modeling mapping code could read from
>> one EC and populate another that uses a modified model. This may not
>> be the most efficient to way to do this, but possibly the most
>> flexible and one that would guarantee data integrity and consistency
>> the most. Any opinions on whether this would be a good idea or not?
>
> I'm sure we've played with that idea some day in the past, if I 
> remember well it
> was probably with Yannick Gingras (I can't check the archives right 
> now).
>
>   The problem is that, while this sounds interesting, this could
>   probably only be done with small databases --because, unless we
>   want to automatically analyse a model in detail, handling
>   relationships will end up in loading a whole database in memory.

OK, as things are it sounds like that in practice it will not be the 
way to go.
It would be difficult to guarantee that the object graph of the target 
EC will stay within a certain size... before the target model integrity 
is respected and one could actually do a saveChanges()...

> Moreover, I'm convinced that it will be difficult to cover every
> transformations. But I can be proved wrong!

Well, I assume that the transformation logic itself will be written 
case-per-case... looping over the tables and their relationships, 
copying/maping them from one EC to another. There should not be any 
limitations there... python is pretty capable ;)

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 with Table_ID, seems rather opaque and awkward to me...

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 = EditingContext(connDict1)
ec2 = 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...

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

mario