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.
> 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).
> 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.
Yours,
Russ Magee %-)
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
