On Tue, 2007-07-03 at 11:51 +0700, Ben Ford wrote:
> Hi All,
> 
> I have a bit of an issue that I'd like to kick around here before I
> start diving into it...
> 
> I'm using the multi-db branch, which I've recently merged all of the
> latest stuff in trunk into. It's all working quite nicely, my app runs
> on PostgreSQL and I have to talk to an Oracle database as well (read
> only). My problem is this; the legacy Oracle database has just been
> split into 2 dbs, the split is by geographical region. So what I have
> now is 2 databases with the same schema (and therefore the same
> models), and I need to get information out of all of them! Here are
> the relevant models as they stand at the moment: 

So the hard case here is where you don't know which database shard you
need to query and so you have to query all of them, right? Otherwise (to
avoid querying all shards) you would need to algorithmically quantify
how to pick the right database.


[... snip...]
> The RANObject (and all of the other classes in that app) will be
> present in two separate databases and I therefore need to be able to
> refer to both from the same model...

In this case, it sounds like you know essentially that "this instance
refers to a RANObject from that database over there". Is that correct? I
must admit that I'm having a lot of difficulty understanding at which
point you know what database something is in. Your example below (adding
an extra field to the model) suggests that all fields from one model are
in one database, at least, so I'll go with that.

 Keep in mind that, like most people, I haven't read the multi-db code,
although I have read the wiki page and vaguely remember some early
design discussions).

> My options as I see them are:
> 
> Another field (db = models.CharField('oracle db', max_length=10) ) in
> the OSSTicketItem which is a the key to the database (i.e. the
> settings.OTHER_DATABASES), this will tell me where the object in
> question lives. Now I need to get the other information from the
> database... so what do I do? 
>       * A custom manager with a method that allows setting the db (via
>         the ConnectionInfoDescriptor) on the fly?

Doesn't sound insane.

>       * A metaclass that changes the internals of the models in the
>         Oracle db(s) to allow specifying which db to look in?

Not sure how this would work. The metaclass methods are called when the
Model class is constructed (so, usually once, at import time). They
don't have a real role to play for class instances (metaclasses are used
to construct classes, classes are used to construct instances). Could
you elaborate a bit on the details here?

Thinking about this quickly here, I would have thought a lot of the real
difficulty was at query time. If I want to look up a particular column
value, I need to work out which database to query. When that is only one
sub-step of a more involved piece of query construction, it could get
quite tricky.

I'm not really sure I'm understanding your problem correctly. A shorter
example might help a bit that just contains the relevant points. It's
difficult to muster enthusiasm to work through three dozen lines of code
like you've presented here. I read through it and I think I understand
which were the pertinent features (it looks like the fields in RANObject
are unimportant for the issue at hand).

Not sure if any of this helps or not. I don't really have a lot of time
free at the moment, so I'm trying to avoid getting too involved in
thinking about multi-db, but maybe that will help others ask questions.

Regards,
Malcolm

-- 
Despite the cost of living, have you noticed how popular it remains? 
http://www.pointy-stick.com/blog/


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to