>> . > > Thanks for the details. What programming language do you use? (Dropbox > uses Python.) >
C++ >> Early on we figured out quite quickly not leverage the read/write >> locking models of SQLite > > Do you use WAL mode? > I played with it early on but I didn't know how stable the feature was and didn't need any of its features at the time, so not at this time. > I'm also curious roughly what you do with your schema. It looks like the > Dropbox on Android schema has elements of implementing a tree with > everything in one big table and no triggers. > We have a file table which is our representation of what the cloud currently thinks of things. Then we diff what the filesystem thinks and describe the differences to the cloud. Once the cloud accepts the event we update our file table. We are careful with triggers and foreign keys since SQLite slows to a crawl when we have those and decide to delete a few thousand rows. > Do you use any of SQLite's extensibilty such as adding your own collations > or user defined functions. > We did have some stored procedures early on but we soon found ways to use the sql language a bit better, which is always a faster option and guarantees use of indices in some cases. We still may have a couple I think but they are not used very much. >> As it stands now, our customers periodically have random I/O errors >> ... > > As you have large deployments, random stuff does happen. We have a web > service with several requests per second from browsers all over the world > and sadly have to use HTTP (cough *IE* cough) rather than the SSL we > normally use. Even though TCP/IP is checksummed there are sporadic > corruptions that come through (typically bit flips here and there). > > 8 years ago there were lots of CPU random errors: > > http://blogs.msdn.com/b/oldnewthing/archive/2005/04/12/407562.aspx > > Do you run an integrity check at startup on the database? I did so with > BitPim, but we didn't have analytics so there was no idea how often > corruption happened. > The integrity check just takes too long so we don't. We are currently brainstorming ways of detecting corruption quickly. > There has been an open feature request for a while to have data checksums > to deal with the case that what SQLite thinks it wrote is not what is > later returned: > > http://www.sqlite.org/src/tktview?name=72b01a982a > Thanks for the info Roger Jason > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAlExZhYACgkQmOOfHg372QTLBgCgsbidy6oQfmAeS4OWq4OBSmFI > zxEAn04lneghgvr+ww76AQWzycZ3x+Q0 > =eya6 > -----END PGP SIGNATURE----- > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users Copy, by Barracuda, helps you store, protect, and share all your amazing things. Start today: www.copy.com. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
