Re: Switching from soc2009/multidb to trunk; cross db foreign keys

On Sun, Jan 3, 2010 at 10:52 PM, Russell Keith-Magee wrote: > On Sun, Jan 3, 2010 at 4:06 PM, CB wrote: > >>> The >>> default implementation would essentially be: >>> >>>     def db_from_related_object(self, instance): >>>         return

Re: Switching from soc2009/multidb to trunk; cross db foreign keys

On Sun, Jan 3, 2010 at 4:06 PM, CB wrote: >> The >> default implementation would essentially be: >> >>     def db_from_related_object(self, instance): >>         return instance._state.db > > I'm not familiar with ._state and not sure if you're referencing > existing attributes

Re: Switching from soc2009/multidb to trunk; cross db foreign keys

> Apologies for taking so long to get back to you on this - the silly > season has been consuming a lot of my time. Silly season indeed :) > I'd go one step further than an attribute - I'd provide a method. I was considering this, but I was thinking about a hacky/internal API for 1.2 instead of

Re: Switching from soc2009/multidb to trunk; cross db foreign keys

On Fri, Jan 1, 2010 at 5:46 AM, CB wrote: Apologies for taking so long to get back to you on this - the silly season has been consuming a lot of my time. > Yes, and I think this is a somewhat common use case. If we could > convince the related managers not to call .using() on

Re: Switching from soc2009/multidb to trunk; cross db foreign keys

Putting the following code somewhere after settings.py is imported (a new app called 'startup' in __init__.py, with 'startup' added first in INSTALLED_APPS is a good place), will allow you to lock models to databases via a manager's forced_using attribute. This definitely not 'the best way', as

Re: Switching from soc2009/multidb to trunk; cross db foreign keys

> Hrm, it's clear that the current implementation is probably overly > aggressive in changing the DB I definitely agree here. It just seems like a useful working solution for 'now', clearly somethign a bit more elegant would be needed to make it into Django's core. > That being said in > your

Re: Switching from soc2009/multidb to trunk; cross db foreign keys

On Dec 31, 3:30 pm, CB wrote: > *Oops, sorry about the refrences to 'AdSalesModel' and setting > using='adsales' - you can see where I'm using these ideas :) > > Change them to PartitionedModel and self.objects.forced_using > respectively. Hrm, it's clear that the current

Re: Switching from soc2009/multidb to trunk; cross db foreign keys

*Oops, sorry about the refrences to 'AdSalesModel' and setting using='adsales' - you can see where I'm using these ideas :) Change them to PartitionedModel and self.objects.forced_using respectively. -- You received this message because you are subscribed to the Google Groups "Django users"

Re: Switching from soc2009/multidb to trunk; cross db foreign keys

So I did some basic poking around with managers, etc. I noticed what 'may be' a 3 part solution to keep a model on one and only one db: First, we should modify the initial queryset to use our preferred db. We can do this by adding a custom manager, with an overridden get_query_set(): class

Re: Switching from soc2009/multidb to trunk; cross db foreign keys

On Thu, Dec 31, 2009 at 12:25 PM, CB wrote: >> In short, you can't (or shouldn't). >> >> What you're asking the database to do is keep a foreign key value that >> is not valid on the database on which it is stored. > > Yes, this is true. > > >> The multi-db branch had checks for

Re: Switching from soc2009/multidb to trunk; cross db foreign keys

> In short, you can't (or shouldn't). > > What you're asking the database to do is keep a foreign key value that > is not valid on the database on which it is stored. Yes, this is true. > The multi-db branch had checks for this sort of referential integrity > until just before the merge;

Re: Switching from soc2009/multidb to trunk; cross db foreign keys

On Wed, Dec 30, 2009 at 6:13 AM, CB wrote: > Hello. > > I've been developing on the multdb branch for awhile now (most recent > version just before the dropping of the 'using' meta attribute), and > everything has been going well. Recently though, with multidb landing > in the

Switching from soc2009/multidb to trunk; cross db foreign keys

Hello. I've been developing on the multdb branch for awhile now (most recent version just before the dropping of the 'using' meta attribute), and everything has been going well. Recently though, with multidb landing in the trunk, I wanted to switch over to the trunk. I have a 'partitioning'