On Mon, Jan 31, 2011 at 7:42 PM, Samuel Adam <a...@certifound.com> wrote:
> I suggested rewriting your schema. Non-TEXT data which will not be > subjected to a MATCH search is best stored in another table and JOINed > with the FTS3 table, as Mr. Hess also explained. Also, specifications > such as VARCHAR(255) are not meaningful to SQLite3; see > http://www.sqlite.org/datatype3.html . Agreed this would be nice, unfortunately we have an gaming console app that's already been through the formal QA process based on a complex SQL schema, and for which the developers are not under our budgetary control. I'd say we have almost no chance of making this happen at this point given the complexity of the application and database (the two fts tables cut across a lot of concerns). Also, I'm not sure how we would avoid the undefined case anyway, because the primary keys for these things are all integers. Presumably this pass-through behavior is what allows integers to be used as join columns even in an fts table. If this edge case persists, where a bound integer ends up as a string internally, won't joins fail as well? I'm working on a standalone test script to narrow down the problem... more soon, and thanks for all your help, Gabe _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
