Re: Multiple database support: Request for feedback and testing

On Sun, Dec 6, 2009 at 12:35 AM, Simon Willison wrote: > On Dec 5, 4:20 pm, Russell Keith-Magee wrote: >> Trust me - I don't want to do mindless busy work. However, we need to >> have some sort of answer for the admin interface - Django's admin is

Re: Multiple database support: Request for feedback and testing

On Sun, Dec 6, 2009 at 1:09 AM, Tobias McNulty wrote: > On Sat, Dec 5, 2009 at 10:51 AM, Russell Keith-Magee > wrote: >> >> I don't grant that proposition at all. The admin interface serves as a >> working example demonstrating that you don't need

Re: Multiple database support: Request for feedback and testing

On Sun, Dec 6, 2009 at 4:16 AM, subs...@gmail.com wrote: > Oh, I see from a later message by Alex that Meta.using was removed. > > -1! There's a very good reason why this was removed. It isn't a model level property. Consider - what if contrib.auth.User had a Meta using='foo'

Re: Multiple database support: Request for feedback and testing

Oh, I see from a later message by Alex that Meta.using was removed. -1! -S On Dec 5, 3:12 pm, "subs...@gmail.com" wrote: > Isn't 'database' going to be an option in a model's Meta? In this > situation, is admin going to attempt to do something different? > > -S > > On Dec 4,

Re: Multiple database support: Request for feedback and testing

Isn't 'database' going to be an option in a model's Meta? In this situation, is admin going to attempt to do something different? -S On Dec 4, 9:18 am, Nan wrote: > > 1) Ignore the problem. Admin works on the default database, but > > nowhere else. This is certainly less

Re: Multiple database support: Request for feedback and testing

On Sat, Dec 5, 2009 at 10:51 AM, Russell Keith-Magee wrote: > > I don't grant that proposition at all. The admin interface serves as a > working example demonstrating that you don't need to use settings to > define the way models are used. > Okay. Do you grant the

Re: Multiple database support: Request for feedback and testing

On Dec 5, 4:20 pm, Russell Keith-Magee wrote: > Trust me - I don't want to do mindless busy work. However, we need to > have some sort of answer for the admin interface - Django's admin is a > big selling point for Django for some people, so we can't really > introduce a

Re: Multiple database support: Request for feedback and testing

On Sat, Dec 5, 2009 at 11:33 PM, Waldemar Kornewald wrote: > Hi Russell, > > On Sat, Dec 5, 2009 at 2:58 PM, Russell Keith-Magee > wrote: >> On Sat, Dec 5, 2009 at 9:05 PM, Waldemar Kornewald >> wrote: >>> On Sat, Dec 5, 2009

Re: Multiple database support: Request for feedback and testing

On Sat, Dec 5, 2009 at 11:15 PM, Tobias McNulty wrote: > On Sat, Dec 5, 2009 at 8:58 AM, Russell Keith-Magee > wrote: >> As best as I can make out, you're addressing the problem that I've >> said we aren't addressing - that of presenting a useful

Re: Multiple database support: Request for feedback and testing

Hi Russell, On Sat, Dec 5, 2009 at 2:58 PM, Russell Keith-Magee wrote: > On Sat, Dec 5, 2009 at 9:05 PM, Waldemar Kornewald > wrote: >> On Sat, Dec 5, 2009 at 12:10 PM, Russell Keith-Magee >> wrote: >>> The idea of using a

Re: Multiple database support: Request for feedback and testing

On Sat, Dec 5, 2009 at 8:58 AM, Russell Keith-Magee wrote: > As best as I can make out, you're addressing the problem that I've > said we aren't addressing - that of presenting a useful end-user API > for tasks like master/slave. If I'm mistaken, feel free to correct me >

Re: Multiple database support: Request for feedback and testing

On Sat, Dec 5, 2009 at 9:05 PM, Waldemar Kornewald wrote: > On Sat, Dec 5, 2009 at 12:10 PM, Russell Keith-Magee > wrote: >> The idea of using a function that returns a single string but does >> other processing is a novel approach, and one that I

Re: Multiple database support: Request for feedback and testing

On Sat, Dec 5, 2009 at 12:10 PM, Russell Keith-Magee wrote: > The idea of using a function that returns a single string but does > other processing is a novel approach, and one that I hadn't > considered. However, I'm not sure I'm especially fond of the idea of > requiring

Re: Multiple database support: Request for feedback and testing

On Sat, Dec 5, 2009 at 4:07 PM, Johannes Dollinger wrote: > > Am 05.12.2009 um 06:36 schrieb Russell Keith-Magee: >> [...] >>> What if the admin was instead fixed >>> by providing facilities for the more general case outlined above? >>> >>> What would this

Re: Multiple database support: Request for feedback and testing

Am 05.12.2009 um 06:36 schrieb Russell Keith-Magee: > [...] >> What if the admin was instead fixed >> by providing facilities for the more general case outlined above? >> >> What would this look like? I'm picturing another setting (bleh) that >> maps apps and/or models to specific databases.

Re: Multiple database support: Request for feedback and testing

On Sat, Dec 5, 2009 at 4:42 AM, Yuri Baburov wrote: > Hi all, > > Database -> Model.Manager -> Queryset. > Save -> Model -> Database > > How about making a default Manager that's now "model.Manager" to be a > setting to override? > Like, calling current Manager a

Re: Multiple database support: Request for feedback and testing

On Sat, Dec 5, 2009 at 3:34 AM, Tobias McNulty wrote: > The very first "Requirement"/ideal feature on the wiki page reads: > > "Different models/applications living on different databases, for > example a 'blog' application on db1 and a forum application on db2. > This

Re: Multiple database support: Request for feedback and testing

On Fri, Dec 4, 2009 at 5:51 PM, Yuri Baburov wrote: > #Isn't it django.contrib.auth? I'm not sure if collision with > 'my.superstuff.auth' might happen or not. It is, but the app registry mechanism in the 'django.db.models.loading' module only uses the "app label", which is

Re: Multiple database support: Request for feedback and testing

AFAICT adding a setting for the default manager just doesn't work because then any models with custom managers either (a) would lose their custom manager, or (b) wouldn't get the manager with using(). Cheers, Tobias On Fri, Dec 4, 2009 at 3:42 PM, Yuri Baburov wrote: > Hi

Re: Multiple database support: Request for feedback and testing

Hi Paul, Tobias, Well, this is god. Few more use cases that will appear on big django installations: Sometimes, with master/slave replication (or legacy read-only databases), users write to one connection, but read from (few) others. Sometimes, with master/master replication, or different

Re: Multiple database support: Request for feedback and testing

On Fri, Dec 4, 2009 at 2:34 PM, Tobias McNulty wrote: > What would this look like?  I'm picturing another setting (bleh) that > maps apps and/or models to specific databases.  Name choices aside, > this might look something like: > > DATABASE_USING = { >    

Re: Multiple database support: Request for feedback and testing

On Fri, Dec 4, 2009 at 2:42 PM, Yuri Baburov wrote: > Like, calling current Manager a DefaultManager, and making "Manager = > load(settings.MODEL_MANAGER) or DefaultManager". Or > Manager.get_queryset calling customizable method. Any. If a suggestion like this is going to be

Re: Multiple database support: Request for feedback and testing

Yes, and the similar function for syncdb can be written too! On Sat, Dec 5, 2009 at 2:42 AM, Yuri Baburov wrote: > Hi all, > > Database -> Model.Manager -> Queryset. > Save -> Model -> Database > > How about making a default Manager that's now "model.Manager" to be a > setting

Re: Multiple database support: Request for feedback and testing

Hi all, Database -> Model.Manager -> Queryset. Save -> Model -> Database How about making a default Manager that's now "model.Manager" to be a setting to override? Like, calling current Manager a DefaultManager, and making "Manager = load(settings.MODEL_MANAGER) or DefaultManager". Or

Re: Multiple database support: Request for feedback and testing

On Fri, Dec 4, 2009 at 3:03 PM, Paul McLanahan wrote: > On Fri, Dec 4, 2009 at 2:48 PM, Alex Gaynor wrote: >> We will not be adding a setting to pin an application/model to a >> specific database.  We have already removed the Meta.using option.  If >>

Re: Multiple database support: Request for feedback and testing

On Fri, Dec 4, 2009 at 2:48 PM, Alex Gaynor wrote: > We will not be adding a setting to pin an application/model to a > specific database.  We have already removed the Meta.using option.  If > you want to pin an application to a specific database it's fairly > trivial to

Re: Multiple database support: Request for feedback and testing

On Fri, Dec 4, 2009 at 2:41 PM, Paul McLanahan wrote: > What will be the default action of manage.py syncdb (without the > --database option)? Will it create all tables on all DBs, or just use > "default"? The former would be useful for the simple replication use > case, but

Re: Multiple database support: Request for feedback and testing

What will be the default action of manage.py syncdb (without the --database option)? Will it create all tables on all DBs, or just use "default"? The former would be useful for the simple replication use case, but wasteful for partitioning, and the latter could get tiresome unless there is a

Re: Multiple database support: Request for feedback and testing

The very first "Requirement"/ideal feature on the wiki page reads: "Different models/applications living on different databases, for example a 'blog' application on db1 and a forum application on db2. This should include the ability to assign a different database to an existing application

Re: Multiple database support: Request for feedback and testing

On Fri, Dec 4, 2009 at 11:40 PM, Tobias McNulty wrote: > Is there a page where one can find a quick summary of the proposed API? > > I have some concerns about implementing partitioning through the admin, but > I expect there's something I'm missing. > > For those who

Re: Multiple database support: Request for feedback and testing

Is there a page where one can find a quick summary of the proposed API? I have some concerns about implementing partitioning through the admin, but I expect there's something I'm missing. For those who haven't been, following the conversation closely it'd be nice to have a quick way to come up

Re: Multiple database support: Request for feedback and testing

On Fri, Dec 4, 2009 at 10:18 PM, Nan wrote: > >> 1) Ignore the problem. Admin works on the default database, but >> nowhere else. This is certainly less than ideal, but it would be >> sufficient for master/slave setups. >> >> 2) Use a separate admin deployment for each

Re: Multiple database support: Request for feedback and testing

> 1) Ignore the problem. Admin works on the default database, but > nowhere else. This is certainly less than ideal, but it would be > sufficient for master/slave setups. > > 2) Use a separate admin deployment for each database. We add a 'using' > argument to admin.Site(), and append .using() the

Re: Multiple database support: Request for feedback and testing

On Fri, Dec 4, 2009 at 6:31 AM, Russell Keith-Magee wrote: [snip] >  1) Do nothing special. This is the currently implement behaviour. As the default, this seems to be the intended behavior only in rare cases (overwriting a different object from the original) and will

Re: Multiple database support: Request for feedback and testing

On Fri, Dec 4, 2009 at 7:31 PM, Russell Keith-Magee wrote: > IMHO, it's best to leave entirely in the hands of the end user. By > that reasoning, The current behaviour (1) is actually the right > solution, along with some documentation explaining the problem and > some

Re: Multiple database support: Request for feedback and testing

On Fri, Dec 4, 2009 at 4:38 PM, Simon Willison wrote: > On Dec 3, 4:10 pm, Russell Keith-Magee wrote: >> Alex Gaynor's GSoC project to add multiple database support to Django >> is on the final straight. The only piece of the puzzle that is left

Re: Multiple database support: Request for feedback and testing

On Dec 4, 8:38 am, Simon Willison wrote: > We now have two blog posts in each database. But, if I do the > following: > > e1.save(using = 'db2') > > It has the effect of replacing e3 with the values from e2, since the > primary keys collide with each other. I meant to

Re: Multiple database support: Request for feedback and testing

On Dec 3, 4:10 pm, Russell Keith-Magee wrote: > Alex Gaynor's GSoC project to add multiple database support to Django > is on the final straight. The only piece of the puzzle that is left is > updating contrib.gis - but this hopefully won't require any major > changes

Re: Multiple database support: Request for feedback and testing

On Fri, Dec 4, 2009 at 12:20 AM, Waldemar Kornewald wrote: > Hi Russell, > I just noticed a simple documentation bug. See the comment at the > bottom of this page: > http://github.com/alex/django/commit/aabfee1571d378dd3b7550573e900850d13e1b9b You are correct. Thanks for

Re: Multiple database support: Request for feedback and testing

Hi Russell, I just noticed a simple documentation bug. See the comment at the bottom of this page: http://github.com/alex/django/commit/aabfee1571d378dd3b7550573e900850d13e1b9b Also, I hope you won't define an API for overriding the query class in the multi-db branch. We'll most likely have to

Multiple database support: Request for feedback and testing

Hi all, Alex Gaynor's GSoC project to add multiple database support to Django is on the final straight. The only piece of the puzzle that is left is updating contrib.gis - but this hopefully won't require any major changes outside of the gis tree itself. Therefore, I'd like to call for feedback