Initial writable database
neptune2000
shell, possibly partially loaded, of the database using code like the
one in the SQLiteBook (createEditableCopyOfDatabaseIfNeeded in
AppDelegate.m)?
Thanks.
Landon Fuller
Right. We also implemented some basic database migration /
initialization support, but haven't finalized the API or decided quite
where to put it yet.
It handles schema versioning automatically -- you just implement a
migration delegate and return the new version.
Code is attached, usage would be:
YourDatabaseMigration *migration = [[[YourDatabaseMigration alloc]
init] autorelease];
PLAppDBManager *manager = [[PLAppDBManager alloc] initWithPath: path
delegate: migration];
// At this point, the database is fully initialized and all
migrations run. Open a connection:
NSObject<PLDatabase> *db = [manager openConnection];
The migration runs inside of a transaction, so any failure results in
a full rollback. We should probably at least post this on the web
site, if not merge it into the main tree.
-landonf
neptune2000
BTW, do you have any "samples" besides the 5-6 lines in the docs?
-- Marco
> 1KDownload
>
> YourDatabaseMigration.h
> 1KDownload
>
> PlausibleAppDatabase.zip
> 24KDownload
>
> PGP.sig
> 1KDownload
Landon Fuller
On May 29, 2008, at 11:46 AM, neptune2000 wrote:
>
> Excellent. Will give it a try. Thanks.
>
> BTW, do you have any "samples" besides the 5-6 lines in the docs?
Other than the docs, we haven't written any official sample code. It
may be worth looking at the unit tests -- they are comprehensive and
should demonstrate how to use all parts of the system.
-landonf
neptune2000
but could not find the unit tests. Please advise. Thanks.
-- Marco
> 1KDownload
neptune2000
tests"?
Oskar Lissheim-Boethius
it would be helpful to link this in.
/Oskar
Charlie Groves
> initialization support, but haven't finalized the API or decided quite
> where to put it yet.
> It handles schema versioning automatically -- you just implement a
> migration delegate and return the new version.
hits CURRENT_VERSION in the switch statement, it just returns YES and
doesn't set newVersion. That means the version in the database is set
back to 0 on the second run of the migrator and that it tries to
migrate from 0 to 1 on the third run. This can be fixed by setting
new version in that case of the switch, but I feel like it actually
makes more sense to set newVersion to currentVersion in
PLAppDBManager. The new version should be assumed to be at least what
the version was coming in, and migrateDatabase's return value is
what's used to signal if the migrator was able to get the db up to an
acceptable version anyway.
Charlie
neptune2000
it and opting to use FMDB, as the footprint is quite different.
-- Marco
On Jun 12, 10:16 am, Oskar Lissheim-Boethius <avoc...@gmail.com>
wrote:
Landon Fuller
On Jul 14, 2008, at 10:18 AM, neptune2000 wrote:
> It compiles and links fine with the iPhone SDK. We anded up not using
> it and opting to use FMDB, as the footprint is quite different.
Resource footprint?
-landonf
Landon Fuller
For the record, this was referring to binary size. Unlinked,
PLDatabase 1.1 object files weigh in at 128K, and FMDB at 96K. This is
primarily due to fixed per-object file overhead. Linked into a
resulting executable, they're smaller.
We don't consider <128K in either direction to be particularly
concerning on the iPhone. I was primarily concerned this was a memory/
cpu resource consumption issue, which is something we're attentive to
and very interested in hearing about should you run into issues.
-landonf