FWIW I agree with Anssi Marc
On 30 June 2014 12:00, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote: > On Mon, 2014-06-30 at 12:56 +0300, Josh Smeaton wrote: > > >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? > > We can continue with as_vendor() no matter what the resolution is. We > already have the exact same problem for Lookups and Transforms, so we > aren't adding new problems by continuing with as_vendor(). > > Michael feels backend.ops.compile() is useful for django-mssql. Also, > multiple core developers think the as_vendor() syntax is bad because it > is monkey patching, or places 3rd party backends in unfair position. I > don't agree, but I don't see other core developers supporting my > position. > > - 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. > > > -- > 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/1404126051.9408.155.camel%40TTY32 > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAMwjO1F2jfnUZaYL_z-ha5k1_fB1WjXFFQdSX_HhNdh1MeMrLw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
