multiple-db-support branch
Alexander Solovyov
Few minutes ago I drop mail to Jason Pellerin and he tolds me that he
can't maintain branch due to lack of time.
So I have question - what needs to happen for merging this branch into
trunk? I read page on wiki (MultipleDatabaseSupport) and examined that
all features are completed but the docs absent in all. So writing docs
will cause to merging branch or something else prevents from this?
--
Alexander Solovyov
Jacob Kaplan-Moss
> So I have question - what needs to happen for merging this branch into
> trunk? I read page on wiki (MultipleDatabaseSupport) and examined that
> all features are completed but the docs absent in all. So writing docs
> will cause to merging branch or something else prevents from this?
Before any large features like this one can be rolled into Django, it
needs a few things:
Testing: from a number of people other than the author -- to verify
that everything works correctly.
Documentation: no big feature can be added without complete
documentation. In particular, a section needs to be written describing
how the change affects existing code, and what the upgrade path (if
any) is.
A maintainer/champion: for any big feature to have longevity, someone
needs to commit to maintaining the code for the foreseeable future.
Nothing would be worse than to merge in something big like multi-db
and have it break in three months because nobody understands it. If
the maintenance plan for a big feature involves forcing me or another
committer to do more work, it's just not gonna work out.
I hate having to say "no" to cool features like multi-db, but since
this is a volunteer-run project, we have a limited amount of time
available. As any good programmer knows, writing code is *much*
easier than maintaining it.
Jacob
Kumar McMillan
> Documentation: no big feature can be added without complete
> documentation. In particular, a section needs to be written describing
> how the change affects existing code, and what the upgrade path (if
> any) is.
The docs have been started:
They probably need clean up and should talk more about migration
(although I think this is fully backwards compatible)
carole...@gmail.com
multiple-db-branch on the wiki page.
I'd be interested in eventually maintaining the code...or helping to
maintain the code...but one of the main reasons I hadn't looked too
much into it is that I'm under a big deadline right now at work...and
he had mentioned merging the code for the branch with the trunk takes
over four hours each time.... so getting started on taking it over
sounded like a pretty big undertaking.
On Feb 28, 2:30 pm, "Kumar McMillan" <kumar.mcmil...@gmail.com> wrote:
> On 2/27/07, Jacob Kaplan-Moss <jacob.kaplanm...@gmail.com> wrote:
>
> > Documentation: no big feature can be added without complete
> > documentation. In particular, a section needs to be written describing
> > how the change affects existing code, and what the upgrade path (if
> > any) is.
>
> The docs have been started:
>
> http://code.djangoproject.com/browser/django/branches/multiple-db-sup...
carole...@gmail.com
unsure where to go to enter them in for tracking. I've got a ton of
stuff working, and these popped up when I was trying to do a few
complicated things.
1. If you are doing a someclass.objects.filter.... and use a
select_related(), on a class that is accessing fields via foreign key
from another table, whether in the same database or a different one
than the main object, everything seems to hang, as if it's stuck in a
recursive loop somewhere. ( I had needed this to do some sorting on
fields that were related by foreign key )
2. If you have an object in one Database ( databaseoneobjectone ),
which has foreign key references to (databasetwoobjectone), and you
try to filter results of (databaseoneobjectone) by saying:
databaseoneobjectone.objects.filter(databasetwoobjectone__someotherrelatedobject__objectproperty__istartsiwith=somevalue)
or
databaseoneobjectone.objects.filter(databasetwoobjectone__someotherrelatdobject__objectproperty__in=somevalue)
It errors out, looking for the 'someotherrelatedobject' in
databaseone, instead of realizing its in database two.
Sorry if that's confusing...I'll be entering these in the bug tracking
system shortly.
Carole
On Feb 28, 8:31 pm, "carole.zie...@gmail.com"
Kumar McMillan
$ ps aux | grep postmaster
do you see more than one process saying something to the effect of
"waiting for transaction?"
you may have created a deadlock (i.e. transaction2 trying to operate
on a locked row, but transaction1 waiting for transaction2 to finish).
Marc Boeren
I just installed the multi-db branch yesterday and I think it is
something that surely must be supported, and I'll play more with it
the coming time. I have a simple schema-evolution idea that does not
alter existing tables, but simply copies data to new tables in another
database. Don't know if somebody is working on that, but it's a nice
way for me to dive into some code :-)
Anyway, one problem with multi-db immediately popped up: you cannot
have duplicate model names, which kind of kills the schema-evolution
idea... I've tracked it down to the ModelMeta class that does a check
on the class name, I'll have a look to see if that can be altered
without breaking anything.
Thanks for all the work on the multi-db branch, I hope it gets merged!
Ciao, Marc.
Simon G.
There's a few multi-db bugs/patches out there, e.g.:
http://code.djangoproject.com/ticket/3613
http://code.djangoproject.com/ticket/3301
If one of the trac-admins can add a multi-db value to the "version"
field in Trac, that would be great. Otherwise, just mark them all as
"other-branch" and put [multi-db] in front of the ticket title like
the others have.
--Simon G.
On Mar 1, 6:39 pm, "carole.zie...@gmail.com" <carole.zie...@gmail.com>
wrote: