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

2009-12-29 Thread CB
ult. In the trunk now, I get a TemplateSyntaxError indicating that the specified Area does not exist. Clearly, it is now looking to the db_extra db for the related area instead of looking to default. Am I doing this correctly? How can I inform django to lookup the foreign key in this db? Th

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

2009-12-30 Thread CB
r way, i'm going to look into this use case myself and try to make it work (in a hopefully not /too/ hacky way) . If you or anyone else has any pointers, please let me know. Thanks, -CB -- You received this message because you are subscribed to the Google Groups "Django users" group

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

2009-12-31 Thread CB
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 Parti

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

2009-12-31 Thread CB
*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" gro

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

2009-12-31 Thread CB
> 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 cas

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

2010-01-02 Thread CB
know. Thanks again to Alex for making the multidb branch. -CB from django.db import models def hijack_for_partitioning(): """This class enables you to add a forced_using = 'db_name' to a manager, which will lock queries and sa

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

2010-01-03 Thread CB
> 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

Calling out for Help!

2011-02-08 Thread Dev@CB
Hello. I hope someone is maybe having a slow day and can spend a little time with me. Here's the whole story: Several months ago, our company started a django project. This project was headed by one man. Well, as of early January, he is no longer with the company. Now, we, the survivors, have the t

Re: Calling out for Help!

2011-02-08 Thread Dev@CB
Tom, why are you discouraging me? -- 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 django-users+unsubscr...@googlegroups.com. For m

Re: Calling out for Help!

2011-02-08 Thread Dev@CB
Andres, Thank you for your kind, helpful reply. Heading to lunch now, more django later! Thank you again, Justin -- 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 unsubscri

Re: Calling out for Help!

2011-02-09 Thread Dev@CB
f I wanted sarcasm I'd start a conversion with my employer. On Feb 8, 12:20 pm, Andres Lucena wrote: > On Tue, Feb 8, 2011 at 6:11 PM, Tom Evans wrote: > > On Tue, Feb 8, 2011 at 5:01 PM, Dev@CB wrote: > >> Tom, why are you discouraging me? > > > My intention w

Re: Calling out for Help!

2011-02-09 Thread Dev@CB
Well, the "python manage.py runserver" command returned a screen full of errors. What would be the appropriate way to post that? I don't want to burn anyone's special eyes. And since we are using Apache, I'm going to say we are also using wsgi. > Well, the first thing to see when deploying a djang