Richard Hipp wrote: > On Thu, Jun 3, 2010 at 11:15 PM, Darren Duncan <dar...@darrenduncan.net>wrote: >> Richard Hipp wrote: > Partition means that one part of the database cannot communicate with > another part. In the usual use of the CAP theorem, this means that the > database is spread across multiple machines and the network link is broken > (or in practice, simply congested and sluggish). In the context of ATTACH > it means that the two databases A.db and B.db cannot communicate with each > other. Of course, they can communicate with each other since they are on > the same machine, but they cannot communicate with each other in the context > set up by the current implementation of ATTACH. ATTACH treats each attached > database as a separate and independent entity. The key point for atomicity > of commits is that each attached database has its own write-ahead log file > and none of those separate write-ahead logs (WALs) know where to find any > other. And so the WALs are effectively partitioned from one other, though > by software design instead of by physical hardware limitations. > > So it seems we could fix this situation by somehow storing in each WAL > information about the location of all the other WALs that participate in > each transaction, thus removing the partition between the components of the > aggregate database.
Yes, exactly. I thought/hoped the solution could be as simple as that. I believe that SQLite is at its best when a multiplicity of databases used in the same connection, as ATTACH provides, are treated as a single database with respect to transactions. An application should be able to use ATTACH when they want these semantics, and the application instead should use distinct connections when they want multiple database accesses that expressly are not subject to common transactions. Generally speaking, I believe that the role of individual SQLite database files is to provide the maximum context for definition consistency, such that every database taken on its own includes all of the context to fully interpret it, and keep it self-consistent. Meaning for example that a table or view or constraint definition is entirely within the database file, and there are no cross-file constraints or foreign keys, say. Both of these principles are orthogonal to whether WAL or journals are used, wherever possible. Therefore, with my WAL comments, I'm not trying to coerce SQLite into being a clone of the more complex multi-file or client-server databases. One might think that from the scope I think that transactions should always have. But my thought on the boundaries of constraints or other definitions should clearly counter this thought. Anyway, keep up the good work; I and others greatly appreciate it. Thank you. -- Darren Duncan _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
