Hi Malcolm,
Thanks for the well thought out response... I've had a bit more of a think
about it over lunch and the metaclass bit is a non starter: it's
instantiation I need to worry about not class creation. In theory I will
always know which database to find RANObjects and their related models in...
the OSSTicketItem will always have a reference to the db based on the third
field I'm going to add to it, and I'll never care about objects in those two
databases if there isn't and OSSTicketItem pointing at it (or one of it's
related classes).
In multi-db at the moment the _default_manager has a data descriptor that
provides the connection object (actually a django.db.ConnectionInfo object)
based on the Manager's model. So I can use that to change db on the fly and
prevent hacking around too much with QuerySet, ModelBase, etc etc... It
looks like I might be able to get away with a sub-class of Manager (and
perhaps a mixin for my models)
I'll have to write some code and see how I go!
Thanks for the help (and the write up on Model Creation and
Initialization!!)
Ben
On 03/07/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
>
> 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/
>
>
> >
>
--
Regards,
Ben Ford
[EMAIL PROTECTED]
+628111880346
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
