On Mon, Jan 31, 2011 at 9:27 PM, Samuel Adam wrote:
> I can’t help you there other than to say, give your boss the facts and
> point out that if QA approved that schema, QA failed its job.
Would that it were it so easy. Unfortunately I work for a startup,
and this code was developed by a partne
On Mon, 31 Jan 2011 15:33:24 -0500, Gabe da Silveira
wrote:
> On Mon, Jan 31, 2011 at 7:42 PM, Samuel Adam 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. He
Here's a standalone script that provides an id field with an int on my
local OS X machine as I desire, and creates an id field with text when
run on the Gentoo machine as breaks the [difficult-to-patch]
application:
https://gist.github.com/aae2366637c94a2861ae
Going home for the night now (London
On Mon, Jan 31, 2011 at 7:42 PM, Samuel Adam 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 no
On Mon, 31 Jan 2011 14:05:15 -0500, Gabe da Silveira
wrote:
[...]
> On Mon, Jan 31, 2011 at 1:24 PM, Samuel Adam wrote:
[...]
>>* Is the database being populated with parameter binding, or
>> not? If so,
>> is id being bound as SQLITE3_INTEGER? (I don’t know off the top of my
>> hea
On Mon, Jan 31, 2011 at 5:34 PM, Samuel Adam wrote:
> According to the docs, results from those queries should be reversed. I
> suspect that Mr. da Silveira’s different platforms actually have different
> SQLite versions, and that one version is consistent with the docs whereas
> the other is no
First of all, thank ou both Simon and Samuel for such thorough
consideration of this problem. I've been in meetings all afternoon
(London time) and will respond to each email where appropriate in
turn...
On Mon, Jan 31, 2011 at 1:24 PM, Samuel Adam wrote:
> On Mon, 31 Jan 2011 07:27:23 -0500, Si
On Mon, 31 Jan 2011 13:37:35 -0500, Samuel Adam
wrote:
> The FTS3
> columns declared INTEGER indeed seem to behave as regular INTEGER columns
> in regular, non-MATCH queries (although I did not test to see if affinity
> would coerce a '1' to INTEGER on insertion).
No coercion is done in the FT
On Mon, 31 Jan 2011 13:16:55 -0500, Scott Hess wrote:
> The FTS3 code mostly passes values directly down to and up from the
> underlying tables, so if you bound an integer, it is likely to come
> back out as an integer when you query.
Just to be clear: In the tests I posted earlier with both 3.
On Mon, Jan 31, 2011 at 9:15 AM, Samuel Adam wrote:
> On Mon, 31 Jan 2011 11:46:21 -0500, Samuel Adam wrote:
>> On Mon, 31 Jan 2011 11:05:13 -0500, Simon Slavin
>> wrote:
>>> In the definition given in the original post, which I quoted, the table
>>> was defined as follows:
>>>
CREATE VIRT
On Mon, 31 Jan 2011 12:34:24 -0500, Samuel Adam
wrote:
> According to the docs, results from those queries should be reversed. I
> suspect that Mr. da Silveira’s different platforms actually have
> different SQLite versions, and that one version is consistent with the
> docs whereas the oth
On Mon, 31 Jan 2011 06:30:55 -0500, Gabe da Silveira
wrote:
> I have an issue with an fts3 table sqlite 3.6.22. I have a PHP script
> that builds an sqlite3 client database for a ps3 application.
> Depending on where I run the build the script (Gentoo or Mac OS X) I
> get a database file that
On 31 Jan 2011, at 5:15pm, Samuel Adam wrote:
> Spoke too soon. SQLite actually ignores the PK definition, and does *not*
> use "id" as an alias for the rowid. Evidence coming in another post; I
> think I found a bug.
Oooh. Interesting.
Simon.
On Mon, 31 Jan 2011 11:46:21 -0500, Samuel Adam
wrote:
> On Mon, 31 Jan 2011 11:05:13 -0500, Simon Slavin
> wrote:
>
>> In the definition given in the original post, which I quoted, the table
>> was defined as follows:
>>
>>> CREATE VIRTUAL TABLE Directors USING fts3(id INTEGER PRIMARY KEY NOT
On Mon, 31 Jan 2011 11:05:13 -0500, Simon Slavin
wrote:
> In the definition given in the original post, which I quoted, the table
> was defined as follows:
>
>> CREATE VIRTUAL TABLE Directors USING fts3(id INTEGER PRIMARY KEY NOT
>> NULL, first_name TEXT NOT NULL, last_name TEXT NOT NULL,
>>
On 31 Jan 2011, at 2:26pm, Samuel Adam wrote:
> On Mon, 31 Jan 2011 08:44:22 -0500, Simon Slavin
> wrote:
>
>> On 31 Jan 2011, at 1:24pm, Samuel Adam wrote:
> [snip]
>>> Actually since this is an FTS3 table, the form with the quotes is the
>>> correct one. As Mr. da Silveira alluded later in
On Mon, 31 Jan 2011 08:44:22 -0500, Simon Slavin
wrote:
> On 31 Jan 2011, at 1:24pm, Samuel Adam wrote:
[snip]
>> Actually since this is an FTS3 table, the form with the quotes is the
>> correct one. As Mr. da Silveira alluded later in his post, in FTS3, the
>> row ID and only the row ID is an
On 31 Jan 2011, at 1:24pm, Samuel Adam wrote:
> On Mon, 31 Jan 2011 07:27:23 -0500, Simon Slavin
> wrote:
>
>> On 31 Jan 2011, at 11:30am, Gabe da Silveira wrote:
>>>
>>> CREATE VIRTUAL TABLE Directors USING fts3(id INTEGER PRIMARY KEY NOT
>>> NULL, first_name TEXT NOT NULL, last_name TEXT N
On Mon, 31 Jan 2011 07:27:23 -0500, Simon Slavin
wrote:
> On 31 Jan 2011, at 11:30am, Gabe da Silveira wrote:
>
>> I have a PHP script
>> that builds an sqlite3 client database for a ps3 application.
>> Depending on where I run the build the script (Gentoo or Mac OS X) I
>> get a database file
On 31 Jan 2011, at 11:30am, Gabe da Silveira wrote:
> I have a PHP script
> that builds an sqlite3 client database for a ps3 application.
> Depending on where I run the build the script (Gentoo or Mac OS X) I
> get a database file that has different semantics for a column declared
> as an integer
20 matches
Mail list logo
