To use FMDB in framework, one should eliminate all non-modular headers. The main culprit here is `#import <sqlite3.h>`. The thing is, FMDB uses SQLite types and constants in these headers, so they had to be removed.
1. Removed `#import <sqlite3.h>` from all of the headers.
2. Moved `sqlite3` and `sqlite3_stmt` declarations in `FMDatabase.h` into `FMDatabasePrivate.h`. FMDB source that needs these will now `#import "FMDatabasePrivate.h" and will have access to them.
3. Removed `#if SQLITE_VERSION_NUMBER >= xxx` logic from the headers.
4. `lastInsertRowId` now returns `long long int`, not `sqlite3_int64`.
5. `sqliteHandle` now returns `void *` not `sqlite3 *`.
6. The `savepoint` and `release savepoint` and `rollback` now always compile regardless of SQLite version (but you'll get SQLite errors if you try those commands with earlier SQLite versions).
7. `makeFunctionNamed` has changed the block parameter type.
8. The FMDatabaseAdditions routines for `applicationID`, much like the `savepoint` routines, will be compiled regardless of SQLite version.
9. Some random usage of deferencing ivars from another class have been replaced with accessor methods.
Note, with all of these changes, in order to conform to modular headers, this is not entirely backward compatible. They'll have to make changes if
- If they referenced the `_db` variable themselves (which they shouldn't be doing anyway; this never should have been in the public interface to start with);
- If they referenced `_statement` variable of `FMStatement` (which is even less likely); or
- If they used `makeFunctionNamed`, the signature of the block has changed (now uses `void` instead of SQLite types).
See issue https://github.com/ccgus/fmdb/issues/309.
The unicode61 tokenizer is now enabled by default and the corresponding build
option is no longer available. FMDB/standaone should depend on sqlite3/fts.
I also updated the comment to emphasize that the most recent stable version of
SQLite is built if the standalone subspec is selected, not a custom prebuilt
version.
Btw.: I am the sqlite3 podspec maintainer and am trying to keep the sqlite3 pod
as close to the official stable release schedule as possible: Delay < a few days
Signed-off-by: Clemens Gruber <clemensgru@gmail.com>
According to the official documentation of SQLite the order in which you call sqlite3_column_bytes and sqlite3_column_blob (and the related methods to retrieve the stored value) is important:
"In other words, you should call sqlite3_column_text(), sqlite3_column_blob(), or sqlite3_column_text16() first to force the result into the desired format, then invoke sqlite3_column_bytes() or sqlite3_column_bytes16() to find the size of the result. Do not mix calls to sqlite3_column_text() or sqlite3_column_blob() with calls to sqlite3_column_bytes16(), and do not mix calls to sqlite3_column_text16() with calls to sqlite3_column_bytes()."
This commit simply changes the order of those calls to conform to the official documentation.
