Hi Ed,
There are a few people looking at multi-db at the moment. I've had to put my
own contributions on hold because I've had rather a hectic personal life
lately, but hopefully I'll be able to crack on with it next week or so.
There has also been some discussion about rethinking some of the des
On Oct 29, 3:31 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> You probably want to start by reading messages here:
>
> http://groups.google.com/group/django-developers/search?q=multi-db&st...
So it sounds as if the branch is dead, and there are patches being
attached to #4747? I'd be willing
On 10/29/07, Ed Summers <[EMAIL PROTECTED]> wrote:
> Does anyone know if there are any plans to merge the multi-db branch
> [1]. I see in ticket #1142 that things are kind of quiet on the
> development side. Did this come up at all during the big spring of
> 14-Sep-2007?
Yo
Does anyone know if there are any plans to merge the multi-db branch
[1]. I see in ticket #1142 that things are kind of quiet on the
development side. Did this come up at all during the big spring of
14-Sep-2007?
//Ed
[1] http://code.djangoproject.com/wiki/MultipleDatabaseSupport
[2] http
I posted this over in django users as well...was getting errors trying
to post in this group.
But I'd like to go ahead and attempt to take over maintenance of the
multi-db branch
I haven't done anything with the Django project as of yet, but I've
got 10 yrs under my belt as
Just wanted to put a note on here...that there are people actively
using this branch. I've been using it since the beginning of
December...and have found it to work fantastically... ( well I did send
JP a bug report today ... with a sample project ... when he told me
this news ).
I do hope in th
Hi all,
I'm afraid that I am not going to have time in the future to continue
maintaining and merging up the multi-db branch. It's diverged so far
from trunk that any trunk change that touches management.py or models
results in hours of hand-merging and svn detective work... hours t
Replying to myself again...
Hacking away at things a bit more, I can see so far only one serious
problem with the implementation outlined above. Moving the connection
information to model._default_manager.db is going to require changes in
django.db.query, specifically in QuerySet._get_sql_clause
> 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 django.db.
[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 databas
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 stru
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 d
> 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 debug,
On Jul 10, 2006, at 11:02 PM, [EMAIL PROTECTED] wrote:
> That wouldn't matter. Maybe if I take out some ellipses it'll be more
> clear:
>
> DATABASES = {
> 'ellington': { 'DATABASE_NAME': 'ellington',
> 'DATABASE_ENGINE': 'postgresql',
> # DATABASE_USE
Jacob Kaplan-Moss wrote:
> 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...
Cool! I'd suggest
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 sur
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
> > setti
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 o
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 t
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 Kaplan-Mos
Howdy folks [especially Jason Pellerin] --
So if y'all haven't yet looked at the multi-database work that Jason
is doing, it's cool shit and worth a look. Start at http://
code.djangoproject.com/wiki/MultipleDatabaseSupport...
I do have some questions for Jason and the rest of the dev commun
26 matches
Mail list logo
