Django developers Google Group

Re: Public method for getting model field names in order of definition

r...@cogit8.org (Rob Hudson) — Sat, 21 Nov 2009 04:25:31 UT

On Wed, Oct 21, 2009 at 6:38 AM, David Chandek-Stark

I do, and have another use case in mind...

For example, let's say you have a Profile model and you have a profile
edit view which uses a ModelForm. In the edit template you can simply
output the {{ form }} or iterate over the form:

{% for field in form %}

Re: Oracle/GIS Testers Needed

alex.gay...@gmail.com (Alex Gaynor) — Sat, 21 Nov 2009 03:55:40 UT

Thanks for taking a look Justin. I won't have time to look into it
myself this weekend, but if you have any questions feel free to ask
here on IRC and I can try to help. Otherwise I will have time this
coming week and can hopefully start digging into this, as it's
probably the single most important tihng to fix up.

Re: Oracle/GIS Testers Needed

jbr...@gmail.com (Justin Bronn) — Sat, 21 Nov 2009 03:52:45 UT

Yes, multi-db is seriously broken with GIS on all backends (it'd be
pointless to list all the errors here). Basically, the massive shift
of `Query` internals to `SQLCompiler` is the root of the problem --
there needs to be a corresponding `GeoSQLCompiler` with `GeoQuerySet`
and `GeoQuery` wired to use it accordingly. I'll try to look at it in

Re: Oracle/GIS Testers Needed

alex.gay...@gmail.com (Alex Gaynor) — Fri, 20 Nov 2009 23:36:00 UT

Thanks!

Unfortunately i have basically no idea what any of those Oracle bugs
mean. However, the few non-frightening errors I saw all also appeared
on trunk, so I guess my refactor basically didn't break anything.

Alex

--
"I disapprove of what you say, but I will defend to the death your

Re: Oracle/GIS Testers Needed

kmtra...@gmail.com (Karen Tracey) — Fri, 20 Nov 2009 20:56:38 UT

I get 6 failures and 26 errors but I do not know if any of them have
anything to do with multidb. The output is here:

[link]

By contrast on trunk I get 7 failures and 26 errors:

[link]

The unable to create INITIAL extent errors are new -- I've not seen them

Design decision on FileField removing abandoned files?

tonightslasts...@gmail.com (Tim) — Fri, 20 Nov 2009 20:24:06 UT

In light of ticket #11663 ([link]
11663), and the consequent discussion on a thread on this group
([link]
491619541ba6ac75).... it doesn't seem like there was any resolution on
the topic of having an optional keyword argument to automatically

Re: Oracle/GIS Testers Needed

ben.for...@gmail.com (ben) — Fri, 20 Nov 2009 16:16:58 UT

No problem, I'll try and spin up some test db's of various versions
next week.

Just to exlpain; the issue is that any date with a year less than 1000
is being output padded with spaces (so year 0001 ends up as u' 1').
This means that serialization is broken for these dates.

At the moment as a workaround I've manually patched my django, but

Re: Oracle/GIS Testers Needed

alex.gay...@gmail.com (Alex Gaynor) — Fri, 20 Nov 2009 16:06:25 UT

I'm not familiar with that ticket, nor the issues surrounding it, so
I'd be uncomfortable applying a patch in any event, further that
ticket isn't specific to my branch so it should go through the normal
process of being committed to trunk, then I'll happily merge it in.

Thanks for offering to run the tests!

Re: Oracle/GIS Testers Needed

ben.for...@gmail.com (ben) — Fri, 20 Nov 2009 16:03:05 UT

Hi Alex,

I have oracle at work with all versions from 9i to 11. I'd be happy to
run the tests on all of those verisons. I wonder if I could ask a
small favour in return though:

In our organisation we have a lot of legacy date/time data modeled as
the year 0001-01-01 and then the time in situations where the time is

Re: Oracle/GIS Testers Needed

alex.gay...@gmail.com (Alex Gaynor) — Fri, 20 Nov 2009 15:17:57 UT

Just running the Oracle tests is enough for now. I've fixed the error
you spotted with the stray import left over and pushed that to github.

Thanks,
Alex

--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero

Re: Session/cookie based messages (#4604)

freakboy3...@gmail.com (Russell Keith-Magee) — Fri, 20 Nov 2009 14:47:48 UT

Looking at this again, it isn't as bad as I first thought, due to a
brainfart on my part. I was looking at the context processor code for
auth and mentally mapping it to the auth middleware for some reason.

However, there is still a lesser version of the same problem -
request.messages.add() will fail outright if you try to invoke it

Re: Session/cookie based messages (#4604)

tob...@caktusgroup.com (Tobias McNulty) — Fri, 20 Nov 2009 13:50:28 UT

Hi Russell, thanks for all your feedback. I'll review the small issues in a
separate email (or just fix them), but here are my responses to the two
bigger problems.

On Fri, Nov 20, 2009 at 3:29 AM, Russell Keith-Magee <freakboy3...@gmail.com

The auth middleware now returns the same thing the messages middleware does,

Re: Oracle/GIS Testers Needed

kmtra...@gmail.com (Karen Tracey) — Fri, 20 Nov 2009 13:26:37 UT

The queries test ran OK once I removed:

from django.db.backends.oracle import query

from django/db/backends/oracle/base .py

I guessed based on the fact that django/db/backends/oracle/quer y.py was
removed in the last commit that the import was leftover from a
restructuring. I am not sure but it looks like there may also be some other

Re: Oracle/GIS Testers Needed

freakboy3...@gmail.com (Russell Keith-Magee) — Fri, 20 Nov 2009 10:53:34 UT

Thanks for the offer. For the moment, only the Oracle stuff requires
testing - GIS will need testing soon. We'll be sure to tap you on the
shoulder again when the GIS stuff is ready :-)

For the moment, the priority isn't testing anything specifically
multi-database. We've made a lot of fairly big changes to the

Re: Session/cookie based messages (#4604)

freakboy3...@gmail.com (Russell Keith-Magee) — Fri, 20 Nov 2009 08:29:56 UT

Here goes. Although there's a lot here, most of the problems are minor
or cosmetic:

* importcls: I can see that the aim here is to reduce code
duplication. However, I'm not convinced it's worth it - the code
you're replacing isn't that complex to start with, only occurs in two
places, and the price paid is a loss of fidelity in the error message.