On Thu, Sep 3, 2009 at 5:00 PM, Russell Keith-Magee <[email protected]>wrote:
> > On Fri, Sep 4, 2009 at 7:14 AM, Craig Kimerer<[email protected]> > wrote: > > I've spent a little time using this branch and looking at the possibility > of > > using it with my project. Below is a short list of problems and ponies > that > > I have encountered (or want). > > > > 1. It'd be awesome if we could mark certain databases as slaves. Inserts > / > > deletes / creates / drops would only run on the masters (table creation > and > > deletion specifically). I can skip the slaves by passing in the > databases I > > want to sync, but I still have the next issue. > > So far, the implemented API is pretty low-level - it lets you direct > queries to a particular database, but the practical end-user API for > use cases such as slave/master hasn't been worked on that much. If you > go back to the original specifications, the suggested solution is to > put this in the manager, and so far I can't see any reason why this > won't work. > But if you list them in settings.DATABASES you have the problem below where tables try to get created on the slaves, which leads to errors because tables cannot be created on the slave. That was my main reason for asking if there was a way to skip them (I should have been more clear). Specifying that queries should come from the master or slave will definitely work in the QuerySet though (and I have been able to do that and have had good progress on it). > > > 2. Only creating tables on the databases specified in 'using'. It's > > confusing (to me) connecting to a database, trying to select all my users > to > > find out I am on the wrong db (because the table is empty). Perhaps > tables > > should only be created on the database they are using. I don't have a > good > > suggestion for this as if you were sharding data, you would want to > create > > the databases on all tables that this model could potentially live on. > > Perhaps using could be be a string or list of connections, > > I think this makes the third time I get to tell Alex "I told you so" :-) > > I agree that this is a problem. We're still working on a solution. I'm > not sure that the Meta: using approach will be enough - consider the > case where you want contrib.auth (or some app you don't control and > doesn't specify using) to be synchronized to the non-default database. > I'm hoping to sort this out with Alex and some of the core devs during > DjangoCon. > > > 3. I have multiple databases defined (some multiple times). It would be > > cool if we could 'ignore' certain databases. An example, I have 3 MySQL > > instances running. MASTER_MAIN_DB, MASTER_OTHER_DB, SLAVE_MAIN_DB. I > want > > to be able to refer to them all, but also all the contrib apps I am using > I > > want to live on MASTER_MAIN_DB. So in my settings I have: > > DATABASES = {'default': MAINDB_MASTER, > > 'MASTER_MAIN_DB': MAINDB_MASTER, > > 'SLAVE_MAIN_DB': MAINDB_SLAVE, > > 'MASTER_OTHER_DB': OTHERDB_SLAVE > > } > > Which means that when I run tests, it tries to drop tables on > MAINDB_MASTER > > twice. Perhaps someone (Alex?) knows of a better way to do this? > > Is there any reason (other than clarity) that you want to be able to > explicitly refer to 'default' and 'MASTER_MAIN_DB'? Is there some > reason that it isn't practical to just call 'default' the main-master > database and refer to it as such? > > The reason I'm asking is that the duplication you are doing here will > result in you opening two different connections to MAINDB_MASTER. I > can't think of an obvious reason that this would e required. I suspect > we could work around the problem if we had some sort of aliasing in > the DATABASES definition (i.e., set up 'default' as an alias of > 'MASTER_MAIN_DB'), but before we add this, I'd like to understand the > use case to see if it is worth the effort (and potential confusion). > I could do that, it was mainly for clarity. Everything inside of my app would specify a using of that database. No other good reason, I can move it over to 'default' and 'default_slave' :). It could be potentially useful for a case where I am developing application I_Want_A_Pony and my models were defined as class SomeModel(models.Model): ... class Meta: using = 'Pony_DB' So users could make them not live on defaults. Although (I haven't tried) it may be possible to do something like... I_Want_A_Pony.models.SomeModel.Meta.using = 'Pony_DB' > > > 4. I am using ContentTypes, and while running tests, if the default > database > > is not created first, then the tests fail with an exception that the > > django_content_type table does not exist. For now I have just hacked it > so > > the default table is created before any of the others. Perhaps there is > a > > better way to fix this problem than that? > > We'll have to look into this. Thanks for the report. > > > For things like #4, where is the proper place to file a bug about that > (if > > there isn't a bug already)? Do bugs from Django branches go in the > normal > > tickets filed on djangoproject.com? > > Yes. There is a soc2009/multidb version identifier in Trac; open your > tickets there and assign them to that version. > Thanks, I should have inspected the creation of tickets more clearly, I looked at all the open ones and saw nothing open for multi-db. I will file that. > > Yours, > Russ Magee %-) > > Thanks for the response, Craig --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
