> The main issue I flagged to Russell in some code review notes was > whether the code needed to be able to handle get_placeholder() output, > instead of hard-coding "%s" everywhere for parameters. If there were > particular column comparisons that required a more massaged approach to > getting the data out of parameters in some cases and if we had to feed > the placeholder functions to the Evaluator or something similar. > > Maybe we don't -- at least, not right now and not for GIS -- which is > fine, too.
Good thing you made me second guess myself. I thought that only the reference to column was needed, but that was the simple case and I neglected the situation where one geo column could be in a different projection than the one referred to in the F expression. Thus, transformation SQL could actually needed (what `get_placeholder` does, but on INSERT and UPDATE), and I've since updated to a newer patch and added some tests. That was a nice break, now back to studying... -Justin > Regards, > Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
