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

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

Delio Brignoli in...@dr... wrote:
> Sebastien Bigaret <sbi...@us...> wrote:
> > Without more details, I guess you intend to do some load-balancing 
> > between db-instances in aread-only app., right?
> 
> not at this stage, load balancing if further down the track, now we 
> need to access several DBs with the same schema, it is a requirement 
> that each customer has is own separate database instance; fixing one 
> fixes the other as well.

Oh oh, so this is something completely different than what I initially had in
mind.

  If I understand you right, you have a reference model, something like
  a template model, that you want to use for every customer account.
  Each one will get its own model, say a copy of the reference model,
  that it should use to access its data in a separate database.

But since in the framework, entities' names share a single namespace, you won't
be able to load two different models with entities having the same name in the
same process.

  What seems to be a serious problem at first sight also suggests that
  there exists a possible and easy solution.

Say your reference model contains one entity 'Document', then for each account
'login', you can create a model named e.g. 'model_login', containing the entity
'Document_login'.  This way you'll be able to dynamically create the models,
create or destroy the dedicated databases from them (see the script
mdl_generate_db_schema.py for details on how this can be done), and access each
account's data in a dedicated database (since every 'model_login' will get its
own connection dictionary, as expected).

 [...]
> My knowledge of the framework is limited, I literaly unpacked the 
> source less than 24 hours ago, ported some of our biz object, logic 
> and have one test from the test suit succesfully complete (by the way,
> being able to express the model in python made my life easier) (in
> case you are interested I tried the dynamic metaclass based approach
> first but I'd get an exception when populating the class as soon as I
> defined an __init__ method: check_old_init method tried to len() args
> but python chocked ;) ) ... 

I'm interested, if you could supply a simple example and fill a bug report
@sf.net that would help a lot ;)

> but back to the issue,
> I'll look into the framework more to understand exactly what it's 
> involved in adding this feature and since I can already hear my boss 
> asking it, I'll ask you straight away how much it would cost to 
> contract you to add this feature (and how long it would take).

Hopefully the solution exposed above can make it; if not, then do not hesitate
to get back to me!


Oh, but wait... sorry, I didn't realize you sent an other email with more
informations:

> What I want to achieve:
> 
> When I create an EC, I'd like to pass the ID string as a parameter and 
> this should give me an EC that works 'like' a plain old connection to 
> the mapped database instance.
> 
> How to get there:
> 
> - change the mapping into: ID -> ( connection params, model )
> ?- subclass EC to support the ID string be passed on __init__
> ?- subclass ObjectStoreCoordinator to use the ID string information in
> EC to create/select a proper 		DatabaseContext.
> ?- at which level caches work in modeling: I obviously don't want rows 
> from different database instances to mixup :-P

Okay, so good news, we're definitely talking about the same thing ;)

So what you need to do is: use the 'ID' (login e.g.) to dynamically build (or
load or...) the corresponding model 'model_ID', use the correct entity in this
model e.g. 'Document_ID' when fetching objects for example, and use the correct
class (that you'd probably want to
dynamic.build...() from the model) to build new objects --this way they get
automatically inserted into the right table in the right database 
(look in class ClassDescription or EntityClassDescription for a method
automatically building the right object of the right class given its entity).

  I think this makes everything work the way you want; and obviously you won't
run into any cache trouble or so, since you're just using different models,
that all!

  What do you think?

-- Sébastien.