> OK, thoughts, anyone?
When i first heard of multi-db i more thought about support for
clustering then moving some apps/models to other databases, which is
great, too of course.
for example: having one master db and some slave dbs that mirror the
master db. requests should go to slaves in some
Replying to myself... here's what I've come up with to explain the
problems I see in my current implementation and what I think should be
done to fix them. Apologies in advance -- it's quite long.
I've implemented a bit of this just to make sure it would work, mainly
the basic parts in
[snip most of OTHER_DATABASES proposal]
> * ``MODELS`` is a list. Each item in the list may be:
>
> * ``app_label.module_name`` if a single model should be use this
> connection.
> * ``app_label`` if the entire app should use this connection
>
> How does this sound?
Good enough for
> What about making Manager callable? It could take a database
> identifier, or even an object with connection info, and return a new
> Manager instance with the specified database info. This would let you
> keep using Model.objects with a default database, or for the case where
> multiple
On Jul 11, 2006, at 8:08 AM, jason pellerin wrote:
> Here's another case that I'd like to see handled gracefully, that I
> think can be handled better with your proposed syntax than mine: one
> app with many models, some of which use a named connection. To me, the
> ideal way to handle that would
A wrinkle occurred to me last night that I really should have thought
of earlier, and that calls into question my whole connection-handling
setup.
When served as a WSGI app in a container like Paste, settings can be
different on every request. That means, first off, that however we
decide to
Trying not to repeat myself too much while arguing for my fast-fading
favorite... :)
> Yeah, you really better, since I don't like it one bit :)
>
> Currently the settings file for lawrence.com has... (/me checks)...
> 48 entries. You mean I've got to duplicate my database settings 48
> times!?
Another use case to mull around:
I'm currently using django for basically everything *but* it's ORM, in
large part due to not supporting multiple databases. We have one
software package with many nearly-identical databases (for different
customers). The models would be the same, but I'd want to
> Under your proposal, I need to write DATABASE_ENGINE and DATABASE_NAME
> once for each application, because there is no way to group the
> information is even one of my applications needs a different database.
> That seems like a lot more configuration (longer config files are harder
> to
On Mon, 2006-07-10 at 22:24 -0500, Jacob Kaplan-Moss wrote:
> On Jul 10, 2006, at 10:09 PM, jason pellerin wrote:
[...]
> >> Finally: will there be syntax to use a specific connection for some
> >> operations even if that model's set up to use a different backend?
> >> I'd hope so, but I'm not
On Jul 10, 2006, at 10:09 PM, jason pellerin wrote:
> Thanks, Jacob. And yes please, more eyes are badly needed. Aside from
> dropping tables, the branch is fully functional -- please try it out!
I've svn swich'd and I'm fooling with it now...
> This is interesting. How would it work -- look up
On Mon, 2006-07-10 at 22:09 -0500, jason pellerin wrote:
> Hi all,
>
> Thanks, Jacob. And yes please, more eyes are badly needed. Aside from
> dropping tables, the branch is fully functional -- please try it out!
>
> > I'd like to see this done the other way around, which the DATABASES
> >
On Jul 10, 2006, at 9:55 PM, Malcolm Tredinnick wrote:
> I agree with most of your points (the settings one is actually kind of
> obvious that it may be backwards now that you mention it).
> Inter-database relations would be nice to have at some point, but it
> could be a post-first-release kind
Hi all,
Thanks, Jacob. And yes please, more eyes are badly needed. Aside from
dropping tables, the branch is fully functional -- please try it out!
> I'd like to see this done the other way around, which the DATABASES
> settings defining which *models* are used. I'm picturing something
> like
I agree with most of your points (the settings one is actually kind of
obvious that it may be backwards now that you mention it).
Inter-database relations would be nice to have at some point, but it
could be a post-first-release kind of feature.
On Mon, 2006-07-10 at 21:38 -0500, Jacob
15 matches
Mail list logo
