>Still, I don't see *any* advantage of doing this compared to just providing the same implementation method in the node itself with the as_vendor syntax
Me neither. I think I confused the subject when I brought up putting differences into the backend - but I was trying to highlight the difference because it's not usually how django does things. If someone has an actual concern with the `as_vendor()` can you please mention it, and why. Otherwise I think we can proceed as-is with the as_vendor. Do you agree Anssi? Josh On Monday, 30 June 2014 18:28:10 UTC+10, Anssi Kääriäinen wrote: > > On Mon, 2014-06-30 at 10:48 +0300, Josh Smeaton wrote: > > > So what kind of hook are we looking at here? Supplying a different > > `.compile()` method that gets the node passed in? Won't that lead to > > all kinds of isinstance checks to see if the compiler wants to change > > the SQL of a particular node? Can you maybe give me a brief example of > > what is wanted here if I've misunderstood above? > > To me it seems there are two options - do isinstance() checks, or > provide a dictionary of class -> method. If you go with isinstance() > checks that could realistically lead to dozens of isinstance checks > chained in a long if-elif list. > > The dictionary approach seems easier to support: > > def compile(self, node, compiler): > if node.__class__ in self.node_implementations: > return self.node_implementation[node.__class__]( > node, compiler, self.connection). > > Still, I don't see *any* advantage of doing this compared to just > providing the same implementation method in the node itself with the > as_vendor syntax. I don't know of any problem that is caused by using > as_vendor(), but avoided using backend specific .compile() hook. > Registering the as_vendor() methods has been the biggest complaint, but > that can be avoided by doing the registration on first __init__ of the > backend - there is no way SQL is going to be generated for given backend > without it being initialized first. > > -Anssi > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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/92b100f7-3daa-4e7b-ade6-7e8fa24ed046%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
