On Jul 16, 4:19 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> On 7/16/07, David Cramer <[EMAIL PROTECTED]> wrote:
> > Is there a specific reason that myfield=Nonedoesn't translate to
> > myfield__isnull=True in the database backend?
>
> The reason is in the implementation details, but, come
I think that instead of executing queries where you want to return no
records and know that no records will ever be returned if a field
lookup is None (e.g. in the case of related objects to an unsaved
object), you should just catch that condition and not execute that
query.
In 9 years I've
On 7/17/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2007-07-17 at 07:28 +0200, Michael Radziej wrote:
> [...]
> > While interpreting __exact=None as "WHERE ... = NULL" might confuse new
> > users, it is probably just what users used to SQL expect (at least for me it
> > comes
Hi,
I'm still surprised that it seems to be only me in my camp ... well ...
I did a bit of research how other python ORMs treat this:
- SqlObject: doesnt't talk about NULL it in the docs
- SqlAlchemy, docs:
# "null" comparison via == (converts to IS)
Just thought I'd mention one other point to consider: at least in
postgresql, there is a configuration option to transform "= NULL" to
"IS NULL" on the fly. [1] So if you're using "= NULL" (which is an
error in virtually all cases) you may get different results on
different databases anyway.
Michael Radziej skrev:
> Hi Adrian,
>
> the current behaviour is not a random implementation detail. It's been
> discussed
> in October 2006:
>
> http://groups.google.com/group/django-developers/browse_thread/thread/e36e80faf653b6d4/15fbf502162bc564?lnk=gst
>
Hmmm, It seems to me that
On Tue, Jul 17, 2007 at 06:55:39AM -0400, Ned Batchelder wrote:
> I'm in the camp that thinks making foo=None useful is a good thing. To the
> python programmer who is our audience, this has a very clear semantic.
> Especially when you take the scenario of using one object's values to create a
>
I'm in the camp that thinks making foo=None useful is a good thing. To
the python programmer who is our audience, this has a very clear
semantic. Especially when you take the scenario of using one object's
values to create a query for objects like it. Having to special case
None seems
On Tue, Jul 17, I wrote:
> first, I really dislike to reopen discussions after more than one year, not
^
Sorry: Should be "than half a year", of course ;-)
Michael
--~--~-~--~~~---~--~~
You
Hi,
first, I really dislike to reopen discussions after more than one year, not
just for this particular question but in general. We won't get anywhere if
don't keep to decisions, except for cases where new and important arguments
appear.
I don't see any new points in this discussion. The "new
On Tue, 2007-07-17 at 07:28 +0200, Michael Radziej wrote:
[...]
> While interpreting __exact=None as "WHERE ... = NULL" might confuse new
> users, it is probably just what users used to SQL expect (at least for me it
> comes quite naturally).
I wasn't convinced by this argument back in October
Hi Adrian,
the current behaviour is not a random implementation detail. It's been discussed
in October 2006:
http://groups.google.com/group/django-developers/browse_thread/thread/e36e80faf653b6d4/15fbf502162bc564?lnk=gst
While interpreting __exact=None as "WHERE ... = NULL" might confuse new
On 7/16/07, David Cramer <[EMAIL PROTECTED]> wrote:
> Didn't know about __ne before today. A lot easier than throwing on
> excludes :)
Whoop, my fault -- the "__ne" lookup no longer exists. You're right,
exclude() is the right way to do it.
Adrian
--
Adrian Holovaty
holovaty.com |
I forsee a patch incoming.. as soon as we make our crazy Django branch
fit w/ trunk :)
Didn't know about __ne before today. A lot easier than throwing on
excludes :)
On Jul 16, 2:19 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> On 7/16/07, David Cramer <[EMAIL PROTECTED]> wrote:
>
> > Is
On 7/16/07, David Cramer <[EMAIL PROTECTED]> wrote:
> Is there a specific reason that myfield=None doesn't translate to
> myfield__isnull=True in the database backend?
The reason is in the implementation details, but, come to think of it,
I agree that it'd be a lot more beautiful if myfield=None
As a beginner in django and databases but not in python i also had
over 2 days to find the is_null filter... None==Null is just more
pythonic and logical. If i may speak for other beginners... please
drop the is_null or wrap it internally when something is filtered
with None.
thanks
On Mon, Jul 16, David Cramer wrote:
>
> It's not so much related to ManyToMany. But None is Python's equiv to
> SQL's NULL.
> [...]
This was discussed and decided long time ago, please search the archives if
you are interested in the reasons.
Michael
--
noris network AG - Deutschherrnstraße
It's not so much related to ManyToMany. But None is Python's equiv to
SQL's NULL.
I'd very much like to see it evaluate to such, and I agree,
isnull=True should be deprecated.
On Jul 16, 9:46 am, "Benjamin Slavin" <[EMAIL PROTECTED]>
wrote:
> On 7/16/07, David Cramer <[EMAIL PROTECTED]> wrote:
On 7/16/07, David Cramer <[EMAIL PROTECTED]> wrote:
>
> Is there a specific reason that myfield=None doesn't translate to
> myfield__isnull=True in the database backend?
Hi David,
You may want to look here: http://code.djangoproject.com/ticket/1050
- Ben
On Mon, Jul 16, 2007 at 09:24:07AM -0700, David Cramer wrote:
>
> Is there a specific reason that myfield=None doesn't translate to
> myfield__isnull=True in the database backend?
myfield = None translates into the SQL expression myfield = NULL. This is not
really that useful, since that clause
Is there a specific reason that myfield=None doesn't translate to
myfield__isnull=True in the database backend?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send
21 matches
Mail list logo
