Hi Karen,
Thank you very much for your thorough answer.
Yes, indeed, using method #2 ('sqlite3.PARSE_COLNAME) in a sample
python script does work with virtual tables using fts3.
I've decided to go with creating the models' 'datetime' fields with
CharFields. I'll probably create some sort of DatetimeString widget
for form processing.
Perhaps later I'll try out experimenting with queryset.extra and the
select
option, like so:
queryset.extra(select={'realupDate' : 'upDate " as upDate
[datetime]" })
But right now, that seems like too much work for the 12 date fields
I have in my models.
Thanks again for you quick response.
Carol Hatcher.
On Aug 3, 8:55 am, Karen Tracey <kmtra...@gmail.com> wrote:
> 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-...
>
> 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
-~----------~----~----~----~------~----~------~--~---
