On Sat, Mar 14, 2009 at 8:35 AM, koenb wrote:
>
> > Is there any downside to checking this in immediately? It's a simple
> > enough change that I don't see it introducing any bugs (famous last
> > words, right?)...
>
> Please don't allow using connections from different database backends
> unless
> Is there any downside to checking this in immediately? It's a simple
> enough change that I don't see it introducing any bugs (famous last
> words, right?)...
Please don't allow using connections from different database backends
unless the problems of using the correct database options are reso
On Fri, Mar 13, 2009 at 11:12 AM, Alex Gaynor wrote:
> To give an idea of what I've suggesting I drew up a small diff(full test
> passage): http://dpaste.com/14018/
I like this. It's straightforward, and it's backwards-compatible. One
particularly nice thing about it is that it gives people the
On Fri, Mar 13, 2009 at 7:57 AM, Jeremy Dunck wrote:
>
> On Fri, Mar 13, 2009 at 7:55 AM, Shai Berger wrote:
> ...
> > Or has some other solution surfaced lately for distributed transactions?
>
> A big fat documentation warning and careful selection of distribution
> strategy?
>
> >
>
To give an
On Fri, Mar 13, 2009 at 7:55 AM, Shai Berger wrote:
...
> Or has some other solution surfaced lately for distributed transactions?
A big fat documentation warning and careful selection of distribution strategy?
--~--~-~--~~~---~--~~
You received this message beca
Hi djangsters,
Last time I had anything to do with multiple databases in a single
transaction, this required two-phase commit[1]. However, barring Alex's
missing document, nobody seems to have brought the issue up; I just wanted to
make sure we are all aware of it. A little check suggests that
> My "nuts and bolts" document ...
Hi Alex,
about a year ago, I spent a few weeks working on multiple database
support myself (building further on the code in ticket #4747).
I used a mercurial trac setup by Ben Ford to store the work and some
notes. It can be found at http://trac.woe-beti.de. (
On Fri, Mar 13, 2009 at 12:26 AM, Adrian Holovaty wrote:
>
> On Thu, Mar 12, 2009 at 11:53 PM, Alex Gaynor
> wrote:
> > Great, since we've moved so quickly on improving our plumbing for this
> there
> > was one other idea I wanted to put forth(since I believe it needs to
> happen
> > for any mult
On Thu, Mar 12, 2009 at 11:53 PM, Alex Gaynor wrote:
> Great, since we've moved so quickly on improving our plumbing for this there
> was one other idea I wanted to put forth(since I believe it needs to happen
> for any multidb implementation). In terms of plumbing the cornerstone of my
> multid
On Thu, Mar 12, 2009 at 11:42 PM, Adrian Holovaty wrote:
>
> On Thu, Mar 12, 2009 at 7:59 PM, Alex Gaynor
> wrote:
> >> I've created a ticket here:
> >>
> >>http://code.djangoproject.com/ticket/10487
> >>
> >> If anybody (Alex?) wants to code up a patch, I'll get it in ASAP.
> >>
> >> Adrian
On Thu, Mar 12, 2009 at 7:59 PM, Alex Gaynor wrote:
>> I've created a ticket here:
>>
>> http://code.djangoproject.com/ticket/10487
>>
>> If anybody (Alex?) wants to code up a patch, I'll get it in ASAP.
>>
>> Adrian
>
> I've gone ahead and uploaded a patch(at this rate they'll be nothing to d
On Thu, Mar 12, 2009 at 7:04 PM, Adrian Holovaty wrote:
>
> On Wed, Mar 11, 2009 at 11:39 PM, Yuri Baburov wrote:
> > Maybe let's go a bit further towards pool of db connections and wrap a
> > bunch of lines importing backend into some function that depends on
> > engine argument?
> > And later c
On Wed, Mar 11, 2009 at 11:39 PM, Yuri Baburov wrote:
> Maybe let's go a bit further towards pool of db connections and wrap a
> bunch of lines importing backend into some function that depends on
> engine argument?
> And later call it with settings.DATABASE_ENGINE to import default backend.
>
>
On Thu, Mar 12, 2009 at 1:26 PM, Yuri Baburov wrote:
>
> On Thu, Mar 12, 2009 at 11:44 AM, James Bennett
> wrote:
> >
> > On Wed, Mar 11, 2009 at 11:39 PM, Yuri Baburov
> wrote:
> >> Maybe let's go a bit further towards pool of db connections and wrap a
> >> bunch of lines importing backend int
On Thu, Mar 12, 2009 at 11:44 AM, James Bennett wrote:
>
> On Wed, Mar 11, 2009 at 11:39 PM, Yuri Baburov wrote:
>> Maybe let's go a bit further towards pool of db connections and wrap a
>> bunch of lines importing backend into some function that depends on
>> engine argument?
>
> FWIW I'm still
On Wed, Mar 11, 2009 at 11:39 PM, Yuri Baburov wrote:
> Maybe let's go a bit further towards pool of db connections and wrap a
> bunch of lines importing backend into some function that depends on
> engine argument?
FWIW I'm still strongly of the opinion that database connection
pooling does not
Hi Adrian,
Maybe let's go a bit further towards pool of db connections and wrap a
bunch of lines importing backend into some function that depends on
engine argument?
And later call it with settings.DATABASE_ENGINE to import default backend.
http://code.djangoproject.com/browser/django/trunk/dja
On Wed, Mar 11, 2009 at 8:36 AM, Narso wrote:
>
> >
> > This is not unlike the code here:
> http://www.eflorenzano.com/blog/post/easy-multi-database-support-django/
> > --
> >
> > Adrian
> Hi, forgive my poor English.
>
> It would be very good to have multiple database support, but to be
> comple
>
> This is not unlike the code
> here:http://www.eflorenzano.com/blog/post/easy-multi-database-support-django/
> --
>
> Adrian
Hi, forgive my poor English.
It would be very good to have multiple database support, but to be
complete, each database may have different engine.
How do you think to s
On Tue, Mar 10, 2009 at 9:15 PM, Alex Gaynor wrote:
> I've posted a patch, but I'd like to here from one of the external DB
> backend maintainers, I know we technically don't have any backwards
> compatibility requirement here, but I don't think we want to jerk them
> around too much. Another th
On Tue, Mar 10, 2009 at 8:56 PM, Malcolm Tredinnick <
malc...@pointy-stick.com> wrote:
>
> On Tue, 2009-03-10 at 12:21 -0500, Adrian Holovaty wrote:
> [...]
> > One ugliness about this is that it has to monkeypatch the settings
> > file in order to change the DATABASE_NAME, before passing it to
>
On Tue, 2009-03-10 at 12:21 -0500, Adrian Holovaty wrote:
[...]
> One ugliness about this is that it has to monkeypatch the settings
> file in order to change the DATABASE_NAME, before passing it to
> DatabaseWrapper._cursor(). So my proposal is to change
> DatabaseWrapper._cursor() to accept a se
On Tue, Mar 10, 2009 at 4:03 PM, Alex Gaynor wrote:
>
>
> On Tue, Mar 10, 2009 at 3:46 PM, Adrian Holovaty wrote:
>
>>
>> On Tue, Mar 10, 2009 at 12:55 PM, Alex Gaynor
>> wrote:
>> > I've been looking at adding multiple database support to Django for a
>> little
>> > while now and as a part of m
On Tue, Mar 10, 2009 at 3:46 PM, Adrian Holovaty wrote:
>
> On Tue, Mar 10, 2009 at 12:55 PM, Alex Gaynor
> wrote:
> > I've been looking at adding multiple database support to Django for a
> little
> > while now and as a part of my plan of action the first step is to remove
> all
> > references t
On Tue, Mar 10, 2009 at 12:55 PM, Alex Gaynor wrote:
> I've been looking at adding multiple database support to Django for a little
> while now and as a part of my plan of action the first step is to remove all
> references to the global settings in django.db.backends.* and replace them
> with a
On Tue, Mar 10, 2009 at 12:21 PM, Adrian Holovaty wrote:
>
> I'm working on adding multiple-database support to an application and
> am building a custom manager that lets me specify which DATABASE_NAME
> to use for a particular model. It looks something like this:
>
> class OtherDatabaseManager(m
I'm working on adding multiple-database support to an application and
am building a custom manager that lets me specify which DATABASE_NAME
to use for a particular model. It looks something like this:
class OtherDatabaseManager(models.Manager):
"""
This Manager lets you set the DATABASE_N
27 matches
Mail list logo
