On Sun, 2007-02-18 at 21:36 +0000, akonsu wrote: > thanks. > > this is good enough, although in general having to fall back to sql is > not portable between different database engines.
It usually is possible, providing you get the table and column names correct (as you indicate below). The main problem I have come across when writing portable SQL with Django was boolean types (SQLite wants '1' and '0', postgreSQL wants 't' and 'f') and I solve this by passing in the Python type True or False as a parameter to the query, rather than hard-coding it. > > i think that at least having methods that return the names of the > underlying database tables and/or fields would be helpful. so that i > could use them in stead of 'myapp_a_bs' or 'a_id'. just in case the > naming scheme changes later. i realise of course that i could go the > other way and make the models use my own names when creating the > tables/fields in the first place. You can extract this information from the _meta attribute on a model. This isn't documented (yet), but it's on the TODO list for things to document before 1.0. For an example of how to extract the information you are after, have a look at [1] (in the "Writing the code" section). If you want to see a bit more what is going on, you can either run "manage.py shell" and import one of your models, then start poking around the _meta attribute in the model (have a look at dir(MyModel._meta), etc), or you can look at the code that is implementing this: django/db/models/options.py. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" 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-users?hl=en -~----------~----~----~----~------~----~------~--~---
