Dennis Cote <[EMAIL PROTECTED]> wrote:
> Ok, I think I'm starting to follow this now. SQLite will scan the index
> definitions in the sqlite3_vtab, and find the index on the PATTERN
> column.
Well, not exactly. But you have the right idea.
> Then it will call the xOpenCursor function to get the index
> cursor returned through the second argument. Then it will call the
> xSeek function, passing back this cursor and the search string as the
> third argument (but I'm still not sure what the second and third
> arguments do).
int (*xSeek)(sqlite3_vtab_cursor*, int nArg, sqlite3_value **apArg,
int *pResult);
nArg is the number of significant terms in the index that are
being used. This is always 1 unless you are dealing with a
multi-column index. There are no multi-column indices in the
proposed full-text search implementation so this is always 1.
The nArg parameter is there because I am trying to make the
virtual table interface as generic as possible.
pResult returns -1, 0, or +1 depending on whether or not the
seek ended up on a record that was less than, equal to, or
greater than the search key. This provides full generality
of the virtual-table mechanism. In the full-text search
implementation, the result would be 0 if there are 1 or more
matches and +1 if no documents match.
>
> The xSeek implementation will parse the search string and do the actual
> lookup in the real full text index. It will then update the cursor to
> "point" to the first record.
>
> Then Sqlite will repeated call xNext to get a pointer to the next
> matching record.
>
> You say the sqlite3_vtab_cursor structure is opaque, but it seems to me
> that the virrtual table implementation functions will need no know about
> its internals to update it.
The sqlite3_vtab_cursor structure will be opaque to the
SQLite core. Each virtual table object implementation
will define its own sqlite3_vtab_cursor structure that
is appropriate for whatever it is trying to accomplish.
(Actually, each implementation will define a structure
with a different name and just cast pointers to and from
sqlite3_vtab_cursor pointers on input and output.)
>
> For each record that is located SQLite will call the xColumn function
> one or more times to get the data for the selected columns (so that it
> can be returned from the SQL query). I don't see a general
> sqlite3_value* argument to this function for the returned value, but I'm
> not sure what the sqlite3_context argument is for.
The xColumn() implementation will use sqlite3_result_XXX()
calls to return the value of the column, just like user-defined
functions do. sqlite3_result_XXX() requires the sqlite3_context
pointer.
--
D. Richard Hipp <[EMAIL PROTECTED]>
