On Mon, Oct 27, 2014 at 9:23 AM, Hick Gunter <h...@scigames.at> wrote:
> SQLite treats each attached database as a separate entity. Attaching the > same file twice is just asking for problems. > > 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. > That's the thing - if we leave out the explicit DB names then it works as expected (or against expectations, depending on one's world view). It's only when adding the explicit db name qualification that it locks. i agree, attaching an opened DB is a huge kludge, but the problem is (summarized): - this app (libfossil) managed 3 different databases. Which one of those gets opened first is unknown/unknowable, and there is no requirement than any of them get opened, or maybe only a subset will. fossil(1) has the same setup but juggles the dbs somewhat differently and does not expose any interface to the outside world, so this has so far remained an "internal" problem with no effect on clients. - sqlite automatically names the first db "main," and provides to way to change that. - end effect is: client code must know which order the dbs were opened in order to know which name is correct for each logical DB. This is a painfully leaky abstraction, though. - a couple months back Simon suggested ATTACHing the db to itself so that we can effectively alias "main" to the well-known name we have specified for that db instance. It worked like a charm until Dave discovered this weird locking behaviour. -- ----- 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
