I'm hopeful that it's possible to devise a scheme that will let SQLite support
multiple readers and writers while completely preserving all of its current
benefits (eg, serverless, efficient, zero-conf, simple API, small footprint).
To that end, I'm trying to understand some of the "sub problems" that get in
the way of multiple writers in order to take a stab at working them out. I can
see that the overall problem is nontrivial and an acceptable solution has not
been found. But this only proves that the problem is hard, not that it's
impossible (*).
Iker
(*) Of course, if folks have actually shown that solving this problem
amounts to squaring the circle then that's another story.
Pavel Ivanov wrote:
>
> I just keep wondering: do you want to write some new database engine
> based on SQLite so that it will heed all these caveats? Otherwise this
> discussion is useless because all these features are not implementable
> on top of SQLite and are way nontrivial to implement inside SQLite...
>
> Pavel
--
Iker Arizmendi
AT&T Labs - Research
Speech and Image Processing Lab
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
