On Fri, 2009-03-06 at 08:00 +0900, Russell Keith-Magee wrote:
[...]
> However, I agree that this would be a useful feature to add (or
> improve). This isn't something we want to be trivial to accomplish,
> but it should be a lot easier for people who are adding fields that
> have unusual operator requirements. I haven't dug into the details to
> work out exactly how we would approach this - any proposals are
> welcome, especially if you can work through the details to see what
> might be possible.
It's certainly on my long-term list (but no closer than that at the
moment). The hard part is keeping the Field classes and the database
storage layer reasonably separate. If people want to combine the two in
their own custom Field classes, that's fine, but I don't want to
introduce even tighter coupling than we already have in Django (there's
some leakage of SQL-awareness into the Field layer, but it's minimal),
because the idea is to make it easy to replace the SQL storage with
something else. So it's the internal API that is the largely non-trivial
part.
Right now, the easiest way to do this stuff is to forget about doing it
as a custom lookup type and do it as a custom Q-like object. Then you
could write something like
Foo.objects.filter(CIDR('my_field', '1.2.3.4'))
Here, CIDR is something like a Q class. Have a look at
django.db.models.sql.Query.add_q() for how anything with add_to_query()
and as_sql() methods are handled.
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
