A possible solution is to just register a custom as_vendor method in the
backend's initialization code.
You could also alter Oracle's compiler.compile() method to check for
backend specific implementation class, and use that instead of the
original one. Something like:
backend_lookup_overrides = {Contains: OracleContains}
def OracleSQLCompiler.compile(self, node):
if node.__class__ in backend_lookup_overrides:
return backend_lookup_overrides[node.__class__](node.lhs,
node.rhs).as_sql(self, self.connection)
As for get_db_prep_lookup(), I think we will need to remove it. It is
doing per-lookup stuff that is now better done in Lookup classes.
Unfortunately we need backwards compatibility for this method as it is a
documented method
(https://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.Field.get_db_prep_lookup)
I don't yet have an idea of how we can actually do the removal without
breaking user code.
- Anssi
On Sat, 2014-11-15 at 14:07 -0800, Claude Paroz wrote:
> Hi Shai,
>
> I was thinking about something very similar for the GIS backends,
> where this question is even more accurate, as lookup implementations
> are often very backend-specific.
>
> I was experimenting with dynamic mixin registration, but that felt
> very hackish [1]. Anyway, a solution to this use case would be really
> welcome.
>
> Claude
>
> [1] https://gist.github.com/claudep/c234e546eab00ff9fdbf
>
> On Saturday, November 15, 2014 8:03:18 PM UTC+1, Shai Berger wrote:
> Hi,
>
> I'v been working on an old Oracle bug[1], and realized that a
> nice way to
> solve it would be by overriding some builtin lookups with
> custom lookups for
> Oracle. However, I had some doubts about where to place the
> code:
>
> On the one hand, I could just add an "as_oracle()" to the
> builtin lookup
> classes. But I felt that would be cheating -- Oracle is in
> core, but what
> would 3rd-party backends do?
>
> So I thought I would implement a custom lookup in the backend,
> which adds an
> "as_oracle", and register that when the backend is loaded.
> Loic commented that
> this is still problematic -- For example, I want to override
> "contains" on
> TextField's, so I would naturally inherit the built-in
> Contains lookup; but if
> a user has two backends which want to override "contains",
> they will be in
> conflict -- only one of them will get to install its handler.
>
> The solution I found was to use dynamic inheritance -- the
> backend inherits
> not the builtin Contains, but the registered lookup for
> "contains" on
> TextField. This way, another backend can also add its own
> as_vendor() method,
> without any of us stepping on each other's feet.
>
> I've posted the initial example of this as a PR[2] for
> comments.
>
> This is related to some of the discussions about transforms
> (SQL Functions)
> that happened on the mailing list a couple of months ago[3],
> but the topic of
> backend-specific functions was not really the topic there, so
> I preferred to
> open a new discussion.
>
> Have fun,
> Shai.
>
>
> [1] https://code.djangoproject.com/ticket/11580
> [2] https://github.com/django/django/pull/3544
> [3]
>
> https://groups.google.com/d/msg/django-developers/HggiPzwkono/dsnx3BuXpnkJ
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/1416206332.8931.192.camel%40TTY32.
For more options, visit https://groups.google.com/d/optout.
