Sorry for the forward, forgot to add the dev group when I sent the mail!
-- Forwarded message --
From: Ben Ford <[EMAIL PROTECTED]>
Date: 11 Oct 2007 10:14
Subject: Re: Multiple DB-Support at django
To: BIERMANS Koen <[EMAIL PROTECTED]>
Cc: "Adam, Mario A
On Fri, 2007-06-08 at 15:27 +, [EMAIL PROTECTED] wrote:
> Right...I understand that although, based on information from
> another post (yesterday I believe) I don't think that is working right
> now, unless the poster was doing something incorrectly... he hasn't
> answered my reply, so I'm
Right...I understand that although, based on information from
another post (yesterday I believe) I don't think that is working right
now, unless the poster was doing something incorrectly... he hasn't
answered my reply, so I'm not sure as of yet.
But in the case that one was using the same da
On Fri, 2007-06-08 at 14:49 +, [EMAIL PROTECTED] wrote:
> We had the need to run some reports across databases, and this
> limitation in the django multi-db branch prevented me from doing them
> correctly...so our DBA wrote up some code using mysqldb that executes
> queries across the dbs... n
We had the need to run some reports across databases, and this
limitation in the django multi-db branch prevented me from doing them
correctly...so our DBA wrote up some code using mysqldb that executes
queries across the dbs... not sure if it is just valid in mysql. Our
dbs are currently all on
On Fri, 2007-06-08 at 13:08 +, [EMAIL PROTECTED] wrote:
> It would be nice if both the trunk as well as multi db fully
> qualilfied all field names with db.table.field name
Where would you want it to do that?
You can't just do it everywhere that the field name is used in SQL,
because it
It would be nice if both the trunk as well as multi db fully
qualilfied all field names with db.table.field name I think that
if this was done, the trunk could actually support multiple databases
as long as the login credentials were the same for all databases and
they were on the same server.
>The Model should probably be keeping track of the database it is on,
>rather than the field. The model base already tracks column names and
>the like; adding a database name wouldn't be out of place. Then, if a
>field references a model, you can compare the remote model's database
>name with the l
On 6/8/07, Ben Ford <[EMAIL PROTECTED]> wrote:
>
> Which tests?
>
> modeltests/test_client/ClientTest.test_session_modifying_view
> returns ok and after that everything stops... I have to kill the bash
> session.
!?!
Sorry, no ideas. Can you isolate the test that is failing by running
the tests
Which tests?
modeltests/test_client/ClientTest.test_session_modifying_view returns ok and
after that everything stops... I have to kill the bash session.
>Are you running MySQL? There are some known test failures due to
>problems in the way MySQL handles row-level integrity.
One of my databases
On 6/8/07, Ben Ford <[EMAIL PROTECTED]> wrote:
> Hi,
> The branch is now up to date as of 5371 (from 4188, yes _stale_ is one word
> you could use) in my local svk repo. Some of the tests are failing, (but
> they're also failing at the same point when I run the tests in trunk too, so
> I'm not qui
Hi,
The branch is now up to date as of 5371 (from 4188, yes _stale_ is one word
you could use) in my local svk repo. Some of the tests are failing, (but
they're also failing at the same point when I run the tests in trunk too, so
I'm not quite sure what's going on!!). As for bug fixes I have my eye
On 6/8/07, Ben Ford <[EMAIL PROTECTED]> wrote:
> Hi Russ,
> Thanks for the reply. What's the prescribed way to track multiple patches in
> one working copy? I haven't had much experience with patches, but I built my
> django base code using patches from a couple of different branch into one
> work
On Jun 8, 12:58 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> We have, in the past, given out branch
> logins to anyone that wanted them. This has, almost without exception,
> lead to stale branches as the developer involved loses interest, etc.
To true - there is an on-going joke on IRC
gt; >
> > Can I suggest doing it the other way round in this case. I believe that
> the
> > multiple-db-support branch has only a small user base and I haven't had
> time
> > to properly test all aspects of the merge, I think it might make it
> easier
> > for o
On 6/8/07, Ben Ford <[EMAIL PROTECTED]> wrote:
> Russ,
>
> Can I suggest doing it the other way round in this case. I believe that the
> multiple-db-support branch has only a small user base and I haven't had time
> to properly test all aspects of the merge, I think it
Russ,
Can I suggest doing it the other way round in this case. I believe that the
multiple-db-support branch has only a small user base and I haven't had time
to properly test all aspects of the merge, I think it might make it easier
for others to test if they can just svn up. There are
On 6/8/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> It would be nice if someone might tell either myself or Ben, how we
> would go about getting the merged code committed, once it's been
> completed and tested or do we just submit it as a patch or
> something on the wiki page for this
ideas here and would be a great maintainer
> > candidate.
>
> > JP
>
> > On Jun 5, 12:27 am, "Ben Ford" <[EMAIL PROTECTED]> wrote:
>
> > > Hi JP,
> > > I've been using your multiple-db-support for sometime now and i wondered
> > >
I am definitely interested and would like to see Ben's merged branch
checked in.
Good work Ben, I am sure getting that branch up to date was difficult.
~Aaron
On Jun 4, 11:27 pm, "Ben Ford" <[EMAIL PROTECTED]> wrote:
> Hi JP,
> I've been using your multiple-d
ve the time to keep up with merging it, let
> alone to add new features or complete the documentation. I think Ben
> has some excellent ideas here and would be a great maintainer
> candidate.
>
> JP
>
> On Jun 5, 12:27 am, "Ben Ford" <[EMAIL PROTECTED]> wrot
Jun 5, 12:27 am, "Ben Ford" <[EMAIL PROTECTED]> wrote:
> Hi JP,
> I've been using your multiple-db-support for sometime now and i wondered if
> you are still actively developing it? I have a couple of suggestions/queries
> to do with a few of my specific needs and I
Hi JP,
I've been using your multiple-db-support for sometime now and i wondered if
you are still actively developing it? I have a couple of suggestions/queries
to do with a few of my specific needs and I would guess those of others...
There are a couple of tickets about this on trac, but I
Done, it's
http://code.djangoproject.com/ticket/3644
A patch is included.
Ciao, Marc.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develope
Please add them to Trac, as it's a good idea to keep an eye on them.
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 wo
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
are you using postgres? if so, when this happens again try typing:
$ 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 wait
I've currently uncovered two bugs so far with this branch... but am
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
I've added a nice document on how to get a project up and running with
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
The docs have been started:
http://code.djangoproject.com/browser/django/branches/multiple-db-support/docs/multiple_database_support.txt
They probably need clean up and should talk more about migration
(although I think this is fully backwards compatible)
--~--~-~--~~~--
On 2/27/07, Alexander Solovyov <[EMAIL PROTECTED]> wrote:
> 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 mergi
Hi all.
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 t
32 matches
Mail list logo
