On Fri, Sep 4, 2009 at 8:56 AM, Craig Kimerer<[email protected]> wrote:
>
>
> 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).
At the moment it is true that all tables are created on all databases,
but that won't be true in the final version. This ties in with my
comment on your original point 2 - we need much better ways to
describe what data is on what database. Create/Write/Read access to
that data is part of that specification.
>> > 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' :).
I'm yet to be convinced that `Meta: using` is actually a good thing.
IMHO, it's the very model of a setting that makes it impossible to
re-use your application. The setting will probably survive into the
final version, but I suspect we need a much better mechanism than
`Meta: using` for most common use cases. Again, this comes back to my
comment on your original point 2.
> Thanks for the response,
No problems. Thanks for taking some beta code for a spin and giving us feedback.
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
-~----------~----~----~----~------~----~------~--~---
