On Thu, 2007-03-15 at 17:24 -0500, Jeremy Dunck wrote:
> On 3/15/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
[...]
> > I would probably call out to another function somewhere to do the real
> > registration,
>
> Sorry, can you pseudo-code this? I'm not sure what you mean by
> another funct
On 3/15/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
...
> Looking at the code I've written, I think the only potential problem
> tnhat jumps out is that constructing some of these things is
> database-engine specific (some of the text matching options,
> potentially), so having access to th
On Thu, 2007-03-15 at 16:42 -0500, Jeremy Dunck wrote:
> On 2/25/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> >
> > I noticed today that a new GIS branch has been created, which includes a
> > goal to develop a custom QuerySet-derivative.
> ...
> > I don't know of any announced plans/wishes
On 2/25/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> I noticed today that a new GIS branch has been created, which includes a
> goal to develop a custom QuerySet-derivative.
...
> I don't know of any announced plans/wishes that affect QuerySets that
> would become more difficult under thi
> I will try and clean up the code today and post it along with some
> examples. Its just a proof of concept, so it can only deal with simple
> forward foreign keys, but I think this approach might just work.
here it is:
very simple example:
>>> from django.contrib.admin import models
>>> import
On 2/26/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> On 2/25/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> >
> > What would the new (QuerySet) world order look like
> >
> > What I propose to do is to split out the SQL construction
On 2/25/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> What would the new (QuerySet) world order look like
>
> What I propose to do is to split out the SQL construction from the body
> of QuerySet and make it into a separate class. This c
Hi Malcolm,
Malcolm Tredinnick schrieb:
> Let's stop going down this path. This isn't a thread about whether to
> switch to SQLAlchemy. If you want to work on that, there is a branch
> already created and a maintainer appointed for that branch. I've got
> nothing against it, but it's not an area
On 2/25/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Let's stop going down this path. This isn't a thread about whether to
> switch to SQLAlchemy. If you want to work on that, there is a branch
> already created and a maintainer appointed for that branch. I've got
> nothing against it, but
On Mon, 2007-02-26 at 06:08 +0100, Michael Radziej wrote:
> Hi,
>
> Malcolm Tredinnick wrote:
> > In passing, moving the query construction out of QuerySet, particularly
> > if we move the database access portions out as well, will make
> > integrating with SQLAlchemy easier -- since it's "just a
Hi,
Malcolm Tredinnick wrote:
> In passing, moving the query construction out of QuerySet, particularly
> if we move the database access portions out as well, will make
> integrating with SQLAlchemy easier -- since it's "just another data
> storage backend".
If you make it a design goal, yes. Bu
On Mon, 2007-02-26 at 11:26 +1100, Malcolm Tredinnick wrote:
[...]
>
> That said, it will be interesting to see what happens in the SQLAlchemy
> branch. However, for right now, I would rather just fix our immediate
> problems: moving query construction into a separate position and redoing
> the m
On 2/25/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> I noticed today that a new GIS branch has been created, which includes a
> goal to develop a custom QuerySet-derivative. There has also been a
> discussion on trying to work out an API for aggregates, which seems to
> be moving along, alt
On Sun, 2007-02-25 at 19:06 +0100, Michael Radziej wrote:
> Hi Malcolm,
>
> I like this since a lot. Your approach to put the SQL construction into
> a different query reminds me much of SQLAlchemy. A quote from their
> tutorial [1]:
>
> """A central concept of SQLAlchemy is that it actually con
On Sun, 2007-02-25 at 18:21 +0100, Honza Král wrote:
> On 2/25/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> >
> > I noticed today that a new GIS branch has been created, which includes a
> > goal to develop a custom QuerySet-derivative. There has also been a
> > discussion on trying to work
Hi Malcolm,
I like this since a lot. Your approach to put the SQL construction into
a different query reminds me much of SQLAlchemy. A quote from their
tutorial [1]:
"""A central concept of SQLAlchemy is that it actually contains two
distinct areas of functionality, one of which builds upon the
On 2/25/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> I noticed today that a new GIS branch has been created, which includes a
> goal to develop a custom QuerySet-derivative. There has also been a
> discussion on trying to work out an API for aggregates, which seems to
> be moving along, al
I noticed today that a new GIS branch has been created, which includes a
goal to develop a custom QuerySet-derivative. There has also been a
discussion on trying to work out an API for aggregates, which seems to
be moving along, although I suspect the design has a bit more work
required yet. Micha
18 matches
Mail list logo
