Starting out on a project that will rely on sqlite for persistence, I’ve be trying to better understand implications of using a pre-backed db vs. one generated programmatically. So far I’m leaning toward the programmatic approach per this question and the iosched app db example.
And that’s all fine, but at this point I’m not sure I could succinctly articulate why that’s a better approach, especially long term.
PS: I ruled out ormlite since domain classes are in a jar lib, already jpa annotated in 2 other apps.
Pre-baked is ok but it introduces a couple of processes that are less than ideal. Firstly you still have to create the database, presumably in an IDE that supports table creation, column entry etc etc. Then you have to save that database in your project and implement the code to instantiate it as your application data base.
This is a great first step for people that are just starting and can later get to grips with the more detailed verbose process of doing it through code.
This process however presents a number of issues. Firstly you’ve lost the steps to create the database, unless you’ve saved sql queries to create the tables. Still they’re not a part of the project that you can tweak and re-run.
As mentioned in the other posts you have a duplicate database consuming space. The database is also much less flexible to accomodate changes and updates.
If your a fan of unit testing then with a coded solution you could look at running tests on the DB generation, that could extend nicely to how you manage database migrations.
So code whilst initially long winded is ultimately more flexible, can be more easily unit tested, ultimately quicker to adopt more complex changes.