Hello All, I have played with the new Virtual Table interface from CVS and found some shortcommings for the current implementation of the xRowID method:
int (*xRowid)(sqlite3_vtab_cursor*, sqlite_int64 *pRowid); As far as I understand, this function is called by SQLite whenever it needs a unique identifer for a row/item as a signed 64 bit integer type. SQLite uses this to pass it back to other Virtual Table methods (most notably xUpdate) so the Virtual Table implementation can use this identifier to locate a particular row/item for deletes, inserts, or updates. I can see two problems here: 1. Using a signed 64 bit integer type works fine for SQLite, but might be insufficient for other Virtual Table implementations. Imagine a Virtual Table which maps the files of a disk/directoy. In Windows, for example, a unique ITEMIDLIST can be generated for a file or folder. However, this ITEMIDLIST is not a signed 64 bit integer, so mapping an ITEMIDLIST to the current implementation is not easily possible. I can even imaginge other scenarios where the virtual table implementation must allocate a special memory structure larger than 64 bit to uniquely identify a row/item. 2. In case the virtual table implementation needs to allocate memory in order to uniquely describe a row/item, this memory needs to be freed when no longer used. As I see it, there is no such method in the Virtual Table implementation. Propsal: A. Maintain the current xRowID interface, but make sure that the sqlite_int64 * can be used by the virtual table implementation in any way it likes, meaning that it is not used internally by SQLite. However, this would not allow counts on the virtual table RowIDs. B. Add a new xFreeRowID merhod, which allows the virtual table implementation to deallocate / free memory which was previously allocated in order to properly describe a row/item. C. Optionally choose a more telling name for xRowID and xFreeRowID to imply a behaviour similar but not equal to SQLite, for example xGetBookmark and xFreeBookmark. D. Optionally offer a second set of methods as proposed in C in addition to the existing xRowID. If xRowID is NULL, there is no RowID available for the given Virtual Table and xGetBookmark and xFreeBookmark are being triggered. if xRowID is not NULL, xGetBookmark and xFreeBookmark are never being used. These are just some suggestions. However, I feel that the Virtual Table idea is currently limited by the 64 bit RowID. If this limit is relaxed, this great idea can be applied to a far wider range of usages. Best Regards, Ralf
