Since I haven't seen an answer, and I probably wrote the quoted comment...
My hope was that we could someday have something like:
db.attach("name");
which would work as you might expect this to work:
db.execute("attach database 'path/name' as 'name'");
Another alternative might be:
db.attach(other_db);
where other_db is a second Database object, with magic happening
behind the scenes.
I think the main reason this has not been implemented is because it
doesn't provide any new functionality which is currently missing. It
would just make certain access patterns more convenient and possibly
more efficient, but you already do have access to all of the data
involved. Also, honestly, I think most people just use a single big
database! This is also a real gray area WRT HTML5, as SQLite ATTACH
is itself not standard.
Implementing this as "in the same directory" manages the same-origin
policy, but is brittle in the face of future changes (if someone later
changes how directories and origins relate, suddenly we might have a
security hole).
-scott
On Sun, Apr 5, 2009 at 8:21 PM, Henchan <[email protected]> wrote:
>
> The Gears database API explicitly disallows the sqlite attach / detach
> commands. This design decision makes good sense to me, for the reasons
> given. Nevertheless the statement below indicates the possibility of
> flexibility.
> "In the future this functionality may be exposed in a way which
> respects the same-origin security policy."
>
> I would like to use this post to make the case for limited support of
> attach / detach. My proposal is to allow multiple attached database
> files, with the caveat that they must be in the same folder as the
> main database file. This would ensure that same-origin policy is not
> violated, yet would enable a useful feature of sqlite.
>
> My objective is to facilitate a secondary vector for distributing data
> between users of my Gears app. The distribution mechanisms need not be
> fully specified at the outset. For example a client-side script, a P2P
> app or just plain old copy/paste/email would all be feasible, if the
> token of transfer were a single database file.
> Using the Gears app to create a separate database file would give the
> originating user control over what data gets transmitted this way (and
> what should remain private). I feel my proposed design would be more
> convenient and flexible for my users than, say, an export / transfer /
> import routine.
>
> It seems to me that Gears and sqlite database files have good synergy
> for Gears developers. Both Gears and sqlite databases are platform
> agnostic. http://sqlite.org/different.html (Stable Cross-Platform
> Database File). The sqlite developers have also committed to maintain
> backwards compatibility for their database file format.
>
> I suggest that other developers who feel that attach / detach
> functionality in Gears would add value to their own apps should voice
> their support to this post.
>
