*** 222,246 **** This method writes the 64-bit rowid of the current row into *pRowid. - *Comments:* - - Not all DBMS use and support the concept of integer rowids. The current xRowID implementation would therefore exclude those databases from being accessed as virtual tables from SQLite. Detailed argumentation follows: - - 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. - - 1: 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. - - *Propsals:* - - 1: 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. - - 1: 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. - - 1: 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. - - 1: 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. This would allow virtual tables which do not support RowIDs, for which SQLite would return the usual 'No such solumn: rowid'. - - I would very much like to see the idea of proposal 4 turn into reality. Even if the above are just suggestions, I feel that the Virtual Table idea is currently limited by the 64 bit RowID. If this limit is relaxed, this great concept could be applied to a far wider range of usages. ---- *xUpdate* --- 222,227 ---- *************** *** 305,307 **** --- 286,316 ---- "B like A". For the form "B like A" the B term is considered the first argument to the function. But for "like(A,B)" the A term is considered the first argument. + + ----- + ***Reader Comments*** + + The documentation for the virtual function methods is above. + The remainder of this file is devoted to user feedback and + commands. + ---- + + *A Comment On Rowids:* + + Not all DBMS use and support the concept of integer rowids. The current xRowID implementation would therefore exclude those databases from being accessed as virtual tables from SQLite. Detailed argumentation follows: + + 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. + + 1: 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. + + *Propsals:* + + 1: 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. + + 1: 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. + + 1: 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. + + 1: 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. This would allow virtual tables which do not support RowIDs, for which SQLite would return the usual 'No such solumn: rowid'. + + I would very much like to see the idea of proposal 4 turn into reality. Even if the above are just suggestions, I feel that the Virtual Table idea is currently limited by the 64 bit RowID. If this limit is relaxed, this great concept could be applied to a far wider range of usages.
Small. Fast. Reliable.
Choose any three.
Choose any three.
|
|