I guess this just proves there's too many multi db threads and that we
are many who're happy Adrian is making it happening. :)
On Apr 6, 11:04 pm, Alex Gaynor wrote:
> On Mon, Apr 6, 2009 at 5:04 PM, Alex Gaynor wrote:
>
> > On Mon, Apr 6, 2009 at 5:00 PM, Andreas wrote:
>
> >> I dont know if
On Mon, Apr 6, 2009 at 5:04 PM, Alex Gaynor wrote:
>
>
> On Mon, Apr 6, 2009 at 5:00 PM, Andreas wrote:
>
>>
>> I dont know if this has been covered in some of the mentioned previous
>> multi db support threads but how is it supposed to work with admin?
>> >>
>>
> It seems rather orthagonal to t
On Mon, Apr 6, 2009 at 5:00 PM, Andreas wrote:
>
> I dont know if this has been covered in some of the mentioned previous
> multi db support threads but how is it supposed to work with admin?
> >
>
It seems rather orthagonal to the admin to me(at least as far as it can
be). The Admin executes qu
I dont know if this has been covered in some of the mentioned previous
multi db support threads but how is it supposed to work with admin?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To
I'm very interested in a cleaner transaction interface. I just wrote
a contextmanager to do the usual "run this code in a transaction" bit,
and it took a day and a half instead of a few minutes.
The goals were typical: to be able to make SQL calls atomically,
without caring about whether a trans
Hi, a nitpick and two material issues:
On Saturday 14 March 2009, Brian Rosner wrote:
> On Mar 13, 2009, at 4:51 PM, Adrian Holovaty wrote:
> > * Transactions are managed via methods on connection objects. NOT via
> > some strange decorator and magic global django.db.transaction variable
> > that
On Fri, Mar 13, 2009 at 7:00 PM, Jacob Kaplan-Moss
wrote:
> Like James, I'm concerned with getting a 1.1 release that's as
> high-quality as possible, and I'm concerned that a big change like
> this late in the game could be too destabilizing to hit our (already
> delayed) release timeline. On to
On Sat, 2009-03-14 at 19:52 +1930, qwerty wrote:
[...]
> What about having an attribute in the Meta class of the model that
> let's the model have a default connection for executing the 4 most
> common different operations in each conneciton, something like
>
> class MyModel(models.Model)
>
2009/3/14 Adrian Holovaty
>
> I've been trying to get a multiple-database setup working with Django.
> Thanks to some trunk changes from the past few days (not to mention
> all of Malcolm's work with queryset-refactor, etc.), doing SELECTs
> from multiple databases is now pretty easy -- and I'd e
On Fri, Mar 13, 2009 at 5:51 PM, Adrian Holovaty wrote:
> My proposal is not necessarily to get this in Django 1.1, but to get
> it in trunk at the very least. I'm selfishly motivated by my own
> project to get this done ASAP, so I'm very happy to do the
> development.
Like James, I'm concerned
On Fri, Mar 13, 2009 at 5:51 PM, Adrian Holovaty wrote:
> My proposal is not necessarily to get this in Django 1.1, but to get
> it in trunk at the very least. I'm selfishly motivated by my own
> project to get this done ASAP, so I'm very happy to do the
> development.
Since 1.1's only about a m
On Mar 13, 2009, at 4:51 PM, Adrian Holovaty wrote:
> * Transactions are managed via methods on connection objects. NOT via
> some strange decorator and magic global django.db.transaction variable
> that comes out of thin air.
I agree that the global functions are not anything to write home
a
I've been trying to get a multiple-database setup working with Django.
Thanks to some trunk changes from the past few days (not to mention
all of Malcolm's work with queryset-refactor, etc.), doing SELECTs
from multiple databases is now pretty easy -- and I'd even call it
"clean"! But INSERTs, UPD
13 matches
Mail list logo
