Re: custom sql portability
> an obvious one is to check whether the query uses standard syntax and
> features. and if not, rewrite it so it does.
>
> also, try to test it on different databases.
For those items that aren't quite so portable, it's helpful to
follow the Django examples like you'll find in
django/db/backends/{backend}/{base|operations}.py for
functionality such as the quote_name and last_insert_id methods.
They vary from back-end to back-end, but by abstracting them to
a function/method call, the correct SQL is created for the given
backend.
-tim
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: custom sql portability
hello, an obvious one is to check whether the query uses standard syntax and features. and if not, rewrite it so it does. also, try to test it on different databases. cheers konstantin On Sep 26, 10:29 am, Filipe Correia <[EMAIL PROTECTED]> wrote: > Hi, > > I'm using some custom sql which isn't probably very portable across > SGBDs. I'm wondering, what strategies do django users recommend to > keep an app portable, even if custom sql is absolutely needed. > > any pointers? > > thanks, > Filipe Correia --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
