> While I know very little about databases, this sounds a lot like any records > not found in the "local" database would be read from a "remote" database. > And any writes would be to the local database with updates to the remote > being managed by an explicit update procedure. And this would happen at the > database level. > > I have no idea whether SQLite, which Fossil is built on, supports this. > Also, Richard has stated that porting Fossil to use another database back > end would be very difficult as Fossil relies on features specific to SQLite. > > I suppose that an "abstraction layer" could be added on top of SQLite. Such > layer would attempt reads on the "local" database, failing over to the > "upstream" database. > > But this would really be a question for Richard and the SQLite team.
SQLite3 can work with multiple databases using "ATTACH DATABASE". But my impression from Richard's "2.1: Scaling" article is that his ideas on communicating with remote repository are mostly database-implementation independent. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
