On Sat, 2009-03-14 at 16:36 +1100, Malcolm Tredinnick wrote:
[...]
>
> I understand what you're saying here, though, so it might not be easy.
> I'll think about it a bit, but I'd like to make that return value
> meaningful on all backends.
Just about to run out the door and I'll be offline until
Hey Russ,
On Sat, 2009-03-14 at 14:10 +0900, Russell Keith-Magee wrote:
> Hi all,
>
> [9967] introduced a failure into the test suite, highlighting either
> an error in the documentation, or a potentially nasty problem that
> requires fixing.
>
> According to the docs[1] :
>
> "The update() me
Hi all,
[9967] introduced a failure into the test suite, highlighting either
an error in the documentation, or a potentially nasty problem that
requires fixing.
According to the docs[1] :
"The update() method is applied instantly and doesn't return anything"
Except... it does.
Further complic
On Thu, 2009-03-12 at 17:50 +1100, Malcolm Tredinnick wrote:
> Hey Gary,
>
> On Thu, 2009-03-12 at 01:40 -0500, Gary Wilson Jr. wrote:
> > Just posted an updated patch:
> >
> > http://code.djangoproject.com/attachment/ticket/689/689.4.diff
>
> If nobody gets to it beforehand, I'll give this a s
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
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 1:58 PM, Gregor Kling
wrote:
>
> Hello there,
>
> Regrettably the IPAddressField implementation is not what I expect :-(.
> Is there by any chance, the possibilty to have a solution that works for
> ipv4 *and* ipv6 in the near future ?
See ticket #811: http://code.django
Hello there,
Regrettably the IPAddressField implementation is not what I expect :-(.
Is there by any chance, the possibilty to have a solution that works for
ipv4 *and* ipv6 in the near future ?
I know you have tons of things to do before the release of the
outstanding 1.1.
So far, I do hav
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. (
19 matches
Mail list logo
