On Wed, 2008-08-20 at 12:10 -0700, Matt Boersma wrote:
[...]
> I now think reintroducing the extra_select approach might work better,
> and perhaps could fix the GeoDjango issues as well.
There's still the offer to add an extra paramater axis to the tuple
inside extra_select if that helps at all
On Aug 20, 1:01 pm, Justin Bronn <[EMAIL PROTECTED]> wrote:
> > Item.objects.dates('created', 'day')[0]
> > DatabaseError: ORA-00923: FROM keyword not found where expected
>
> That's the exact error that's giving me problems -- I think it's one
> of the same issue as I'm having. It's because of t
> Item.objects.dates('created', 'day')[0]
> DatabaseError: ORA-00923: FROM keyword not found where expected
That's the exact error that's giving me problems -- I think it's one
of the same issue as I'm having. It's because of the `col.rsplit('.',
1)[1]` logic in Oracle's `as_sql` when doing offs
On Wed, 2008-08-20 at 10:03 -0700, Matt Boersma wrote:
> On Aug 20, 10:50 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
> > There's one SQL syntax error that I can't fix, however (in
> > regressiontests/queries/models.py). I'll look at the pickling issue
> > there, but the SQL problem I can
On Aug 20, 10:50 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> There's one SQL syntax error that I can't fix, however (in
> regressiontests/queries/models.py). I'll look at the pickling issue
> there, but the SQL problem I can't debug.
If you mean this one:
Item.objects.dates('created', 'd
On Wed, 2008-08-20 at 09:47 -0700, Matt Boersma wrote:
> Hi Justin,
>
> Sorry, I should have run the gis tests as well. (Is that Malcom
> snickering I hear? I'm chastened.)
I'm not snickering. We're chasing a lot of things here and cascading
changes are kind of to be expected. Just like they
Hi Justin,
Sorry, I should have run the gis tests as well. (Is that Malcom
snickering I hear? I'm chastened.)
Did GeoDjango break in r8426 then, as Oracle in general did? That's
where extra_select changed. I can see how our new code in r8445
breaks on your function column.
I'll look at it t
> Rather than flag "row_number()" as an extra_select parameter (and then
> try to clean up after it later), Oracle now just uses the default
> set_limits and clear_limits methods and does all extra query munging
> in its as_sql() method. And instead of doing an outer SELECT *, we
> SELECT specifi
Thanks very much for the pointer, Ramiro. It was indeed changes to
the "extra_select" QS param that caused Oracle problems, and I've
taken a similar approach to yours in fixing it.
Rather than flag "row_number()" as an extra_select parameter (and then
try to clean up after it later), Oracle now
On Mon, 2008-08-18 at 17:20 -0300, Ramiro Morales wrote:
> Matt,
>
> On Mon, Aug 18, 2008 at 4:04 PM, Matt Boersma <[EMAIL PROTECTED]> wrote:
>
> >
> > Here is Leo Soto's buildbot, so you can see what I'm talking about:
> > http://certenium.ingenium.cl:8080/hudson/job/django-trunk/
> >
> > I'll
Matt,
On Mon, Aug 18, 2008 at 4:04 PM, Matt Boersma <[EMAIL PROTECTED]> wrote:
>
> Here is Leo Soto's buildbot, so you can see what I'm talking about:
> http://certenium.ingenium.cl:8080/hudson/job/django-trunk/
>
> I'll do my best to fix some of these as time permits, but I'm hoping
> others wi
could work with us on
this as the backend maintainer there, it would be helpful. I'm obviously
not intending to break the Oracle build, but I'm also not in a position
to do more than document cleanly what's going, try to be pre-emptively
careful and answer questions about specific quickly.
This is just a heads up since clearly some committers must be unaware:
checkins of the last two days have created 27 (yes, twenty-seven) new
test case failures for Oracle. I had been working on cleaning up the
existing few failures for the Oracle backend, but unless those who
actually committed t
13 matches
Mail list logo
