On Sun, Aug 2, 2009 at 7:06 PM, Carol Hatcher <etmo...@gmail.com> wrote:
> > Hi, > > I'm using Django 1.0 and 1.1, pysqlite2 (latest version), sqlite3 > (latest version) and FTS3 (latest > version). > I'm creating some Django models where I recreate the database tables > as virtual tables using > FTS3 so that we can do full text search. > Some of the fields in the tables are datetime fields. > We preload the database tables by reading datafiles, building the > appropriate Django models > and saving them using the the models.save() method. > The datetime fields go into the database as datetime objects but > they come back out (called with objects.get(pk=<id>)) as unicode > strings. > Integer and string data go in and come out fine. > I don't see the database adapter/converter invoked. ( I put a print > statement into the code) > > If I don't recreate the tables as virtual tables using FTS3, > everything works fine. > I see the database adapter/converter invoked. > > Does anyone know what might be going wrong here? > >From a little research on the virtual tables used by sqlite's full-text support, I'm wondering if these tables support maintaining the type information that the Python interface uses for the converter functions. Specifically on this page: http://www.sqlite.org/cvstrac/wiki?p=FtsUsage it states that, for the CREATE VIRTUAL TABLE, "Any additional information, including constraints and type information, is ignored." Also, "The set of columns which can be referenced are exactly those enumerated in the create statement, all of which will appear to be of type TEXT". If all of the columns appear to be of type TEXT to clients accessing the tables, I do not think the client (Python interface) will have the information it needs to know when to invoke the registered converter functions. To test this, I'd try a program similar to the sample one here: http://docs.python.org/library/sqlite3.html#converting-sqlite-values-to-custom-python-types only modified to use fts3 virtual tables as you are. I believe Django is relying on method #1 (using declared types) to cause the converter functions to be called. If that sample does not work for the fts3 virtual tables than I think that would explain why Django's registered converter functions are not being called for these tables. If method #1 does work for the sample program on virtual fts tables, then it's not clear to me why Django's converters aren't being called, unless you dropped the type information during creation of the virtual tables. If method #1 does not work, but #2 (using column names) does, that would be interesting to know. It might point to a way Django could alter its sqlite sql to support getting converters called for these tables, but I have no idea how feasible such a change would be. Someone with more ORM/backend experience would have to give an opinion on that. Karen --~--~---------~--~----~------------~-------~--~----~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
