1223105 - Don't synchronously initialize the database access layer

Status: NEW

(Firefox for iOS :: Data Storage, defect)

Description

[Richard Newman [:rnewman]]

See Bug 1223017.

We can't ever synchronously act on our databases from the main thread.

That means we can't assign them in init if assignment implies full construction, nor can we initialize tables in init, nor can we block on actions that touch the DB in most places.

In order to get to this point we need two things:

* BrowserDB needs to be a lazy wrapper that only exposes asynchronous methods. Internally it will "chain on a promise" -- do work after init has been done. We can do this with dispatch_once.

* SQLiteHistory et al -- consumers of BrowserDB and each other -- need to expose Deferreds to allow them to chain off each other's delayed initialization. So one might do:

  self.profile.history.addLocalVisit(visit)

which will be:

  SQLiteHistory.swift:

    public func addLocalVisit(visit: Visit) -> Success {
        return self.init() >>> {
             // Old function body goes here.
        }
    }

    ...

    public required init(db: BrowserDB) {
        self.db = db
    }

    ...

    public func init() -> Success {
        return self.db.init() >>> {
            // Old init goes here.
        }
    }



... or something equivalent.

The scary thing about this is that our motivation for doing so is to unblock the main thread, but if we take thirty seconds to open the DB the UI will be sparse and useless. We don't want to queue up behavior like deciding whether to show the bookmark star, and we don't want a blank top sites panel.

That leads me to wonder whether we should WONTFIX this bug. But I thought I'd write it up regardless.