On Wed, 2009-01-07 at 13:28 -0800, Justin Bronn wrote: [...] > I'm -1 on moving conversion operations from the Query class to the > backend. However, I'd be +1 if Query.convert_values is kept -- even > if it's just a wrapper around self.connection.ops.convert_values. If > the conversion functions are _only_ available at the backend level, > then it would mean I would have to create distinct spatial database > backends every time I want to subclass the convert_values() method. I > don't want to have to create distinct database backends just so I can > override a single method (DATABASE_ENGINE='gis_postgresql_psycopg2' > looks pretty awful to me).
The general principle that Justin's mentioning here: providing a general method that possibly calls a backend method is something I like as a rule. It allows one to provide some non-backend-specific extensions more easily. So I agree with Justin in terms of how any refactoring might happen: leave a Query-level entry point exposed. > > Is GeoQuery likely to have a base class other than OracleQuery in the > > Oracle case? > > No; unless, of course, the backend requires a custom Query class like > Oracle does -- which would mean any future backends without LIMIT/ > OFFSET and spatial support would also subclass from the backend's > Query class. MS SQL Server support being one case that's likely to crop up as an external project at some point. Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
