Add an fcmodel override point for init (or pre-init)?

[xilvar]

In heavily asynchronous startups it would be nice to have somewhere to override which would let you go ahead and open your db the first time someone tries to instantiate an object. For example, if [FCModel init] was the designated initializer for FCModel you could do something like this:

-(MyModel*)init
{
[MyDB ensureOpen];
self = [super init];
if(self) { ... }
return self
}

Since it's possible to create a singleton pattern which involves only one comparison to check for instance existence in the already exists case, the performance impact would be negligible. Especially if the user implemented ensureOpen as a c function instead of a message.

didInit doesn't work for this because it happens after the db was already tried. An alternative is to override all of the instance instantiators, but that's pretty messy and fragile.

[ahti]

Problematic about this idea is that for example instancesWhere: queries the database before ever creating a model instance.

Also opening a database from disk sounds like it is (correct me if I am wrong) an operation that takes a significant amount of time (especially considering migrations) and you wouldn't want to happen at any random point in your code (wherever a model object is first instantiated).

I think you are far better off just opening the database in a dispatch_async call from application:didFinishLaunching... and not presenting any usable ui until that block finishes. Chances are good that your first screen makes some database calls anyway, and if that is the case, your idea might actually lead to blocking the main thread in didFinishLaunching for some time, which is not very desirable.

[ondrejmirtes]

Also long blocking of the main thread on startup leads to the OS killing the app before it has a chance to launch.

[xilvar]

I sort of assumed that opening an sqlite db was pretty much similar to opening a more complex db. Essentially just reading of the metadata regarding table structures because it would be pretty silly to do significant work for a db open. I'll do some testing later to see what actually happens.

That being said, I bet virtually everyone using fcmodel at least starts out opening the database from the main thread because it's the most obvious way to do it and doesn't seem terribly costly. Plus if you're using some sort of model concept at all you probably need your model to behave consistently throughout code execution.

Of course the 'right' way to do it if it does in fact take significant time is probably to structure your code to have a 'startup' ui which runs the run-loop but doesn't actually allow procession forwards into any area which might use the model until a dispatched open of the db occurs.

[ahti]

Opening a sqlite db may be lightweight (I don't have any data about this). Migrating a big set of user-data across several changes to your db structure is definitely not lightweight, and is something that may happen.

The 'startup ui' approach is the one I am taking in the app I am currently working on. The startup UI is barely visible (fractions of a second), and that is with a crossfade animation between it and the 'real ui'. Still I don't want to run into situations where migrations take too long, the watchdog gets impatient and kills my app.