scott, Thanks for your reasoned response. Given the absence of support from other group members, it looks like this has little demand traction anyway. The request was along the lines of your other_db scenario.
Perhaps we could just clarify my particular use case, which seems to contradict your statement > it doesn't provide any new functionality which is currently missing. What I'd like to do is to join the same table from several different sqlite database sources. I'd construct my select statement dynamically, according to which databases were needed. True, I could query one Db at a time and combine the results in my javascript, but a sql join would be both a headache to program (beyond my skill) and inefficient even if I could manage it. Just thought of something else though ... load the various sources into a temp table and query that. Will try it as a workaround. On a different note, your comment about HTML5 is interesting. Has there been any road-map published whether / how / when Gears might fold into HTML5. Going into this I already understood that Gears was probably just an interim solution. Still it would be great to see a road-map if one exists. - Henchan On Apr 22, 8:48 am, Scott Hess <[email protected]> wrote: > 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.
