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: Should docs.djangoproject.com link to 1.1 frozen docs by default, not SVN dev docs?

This should be a high priority fix. Anyone new to Django and using the installation of 1.1.1 (which the download page recommends over trunk) will currently be unable to follow the tutorial. I was having a face to face meeting today with someone who had exactly this problem. On Nov 6, 1:53 am,

Re: Signals for ManyToMany relations question

On Sat, Dec 5, 2009 at 5:35 AM, Ryan K wrote: > > I hope I'm not missing something glaringly obvious but the idea would > be that an option in the Django instance's settings would enable this > feature (or maybe as a decorator for each model or explicitly giving > the model

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: Signals for ManyToMany relations question

Correction: "Surely this would be much slower but for situations where write's are very [IN]frequent it's okay to pay." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Re: Signals for ManyToMany relations question

Okay, thank you for clarifying the problem. I admit that I am least familiar with the database operations as they are implemented in Django so I will read the relevant code and see if indeed something _can_ be done. This is not a bug at all but I think it raises a valid question. Signals are

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

Django sprint in Dallas - Dec 12 & 13

Hi All, There will be a local Django Development sprint in Uptown Dallas next weekend (Dec 12 and 13). A development sprint is an excuse to get together, write some code, and have a good time doing it. The purpose of this sprint will be to help finish features and push out bug fixes in

Re: #7052 - Fixing serialization for contrib.contenttypes and contrib.auth

On Fri, Dec 4, 2009 at 7:38 AM, Russell Keith-Magee wrote: > On Fri, Dec 4, 2009 at 7:03 AM, Luke Plant wrote: >> On Thursday 03 December 2009 15:33:44 Russell Keith-Magee wrote: >> >> How easy would it be to fix this? If you used a list of string

Re: Regularly-scheduled Django sprints, first December 11 - 13

On Wed, Nov 11, 2009 at 3:57 PM, mrts wrote: ... >> As I have said to you in the past - if you want to make your >> contribution to Django to be a DVCS  repository that acts as a staging >> area for trunk-ready patches, that would be a very helpful >> contribution. This is

Re: Regularly-scheduled Django sprints, first December 11 - 13

On Wed, Nov 11, 2009 at 5:57 AM, Russell Keith-Magee wrote: > > On Wed, Nov 11, 2009 at 1:06 AM, mrts wrote: >> >> Great news! Have you discussed the workflow yet? >> I.e. will a DVCS be involved, and if yes, will there be >> a central repo for

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: How do I tap into admin.py to generate data from models?

On Sun, 29 Nov 2009 09:42:23 -0800 (PST) Joshua Kramer wrote: > > I am currently modeling the SQL creation code in sql.py and > creation.py, as well as the field type code in fields.py. So I'm on a > good track - now where should I look to hook into admin.py? Override

Re: Signals for ManyToMany relations question

On Fri, Dec 4, 2009 at 3:44 PM, Ryan K wrote: > Sorry for the confusion but I sent the original link from my mobile > handset which isn't great for copying/pasting/etc. In future, could I please ask you to consider that when you send a message to django-developers, it