On Mon, Oct 27, 2014 at 8:52 PM, Nico Williams <n...@cryptonector.com> wrote:
> Well, it could do something to detect duplicates, but it may not be > easy (or even possible) to portably detect that two DB files are the > same file. The same is true for the application, of course, but it > seems reasonable [to me anyways] to put this burden on the > application. > It doesn't seem unreasonable, i agree, and i have no doubts that our use case is an odd one. (Background: we're migrating the fossil monolothic app to a library API, and that's where the history of these DBs, and how they are handled, originates.) > Still, I can see how it could be useful for SQLite3 to detect dup DB > ATTACHes. Suppose you had a two-DB application, but since there's no > schema conflicts you later decide that it'd be easier (e.g., easier to > backup, sync, manage) to merge the two DBs into one. But you still > have older code that wants two DBs... > That's conceptually the same problem we're trying to solve here: keep the public db names stable, regardless of where/how they're actually attached. Background: my initial feature request (from a thread in July) was the ability to assign an alias to any given db handle, such that "myalias" would work just like "main" or "attachedName", but ATTACH was suggested and turned out to work like a charm until Dave went and broke it with a self-locking query (and then, bless his heart, went and debugged it to its conclusion) ;). > The query specifies that the destination db be locked for write and the > source db for read; which translates to two locks that cannot coexist on > one underlying db file. > > And two journals, and so on. > Oh, good point - hadn't thought of that. On a related note, as of an hour or so away we've migrated to a "" (initially ":memory:", but "" (which was new to me) seems a better fit) plus (pragma temp_store=file), and we're attaching the other DBs as needed. There's one particular use case which has hypothetically has minor breakage if the power goes out at one particular point in one specific cross-attached-db transaction, but because (as i understand it) each individual attached DB is guaranteed to be consistent within itself, the damage (if any) for our case is harmless (record ID mismatches in the "more transient" of the DBs) and would be recoverable by a routine scan which client apps do anyway, so it's unlikely that a user would ever even see it. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
