Hey Christopher, On 2011-03-28, at 7:10 PM, Christopher Armstrong wrote:
> Hi Eric > > On Wed, 09 Mar 2011 14:52 -0700, "Eric Wasylishen" > <ewasylis...@gmail.com> wrote: > >>> afaik it isn't yet. Eric is still investigating various architecture and >>> API ideas. >> >> Yeah, I'm still working on redesigning/rewriting.. I'm really hoping to >> focus on this in the next few weeks and get something finished! > > Against Quentin's better advice :-), I begun experimenting with your > first ObjectMerging (OM) prototype in GNUstep with EtoileUI to try and > understand how to integrate it. I was able to load and save simple > documents that consist of a flat list of data. > Cool! Any help/ideas you can offer would be great. I have to admit I'm stuck right now. > I've noticed you've switched to sqlite for OM4 instead of multiple > property lists. It wasn't a very deliberate change, I just wanted to try keeping everything in one "log" table in sqlite as an experiment. > I just wanted to confirm some things: > > > * Do you plan to use one sqlite database for the whole workspace of one > user? > This seems to make sense, given that it would be difficult to search > multiple (offline) databases if there was one database per document. I was thinking about this too. I agree - if we had one DB per document, doing a full-text search would involve running a query on the DB of each document we want to search in, which would defeat the point of having a full-text index in the first place. > As > you probably know, sqlite locks the entire database for each write > transaction made by a process. I don't think this is a problem for > offline applications as a single user will typically interact with only > one application at a time. I think it may be a problem for network > applications, as they will be writing data they receive from network > connections at random intervals, which might cause some performance > problems given that the sqlite FAQ suggests it might be only able to > handle a few dozen transactions a second (as each transaction involves a > couple of round-trips to disk to ensure the data is written). > One thing we could try is write-ahead log mode: http://www.sqlite.org/wal.html It sounds like a good fit for what I expect our usage patterns to be. In any case it's as easy as one SQL command to turn it on/off. :-) > * Was there a plan to move to some kind of server for the object > meta-data database? It seems we are able to avoid it with sqlite because > of its file locking. > My feeling is that we should just open the DB directly in each process for now. We can always try a server approach if needed, but I don't think it will be. > * On a similar note, will you continue storing blobs of objects in the > database, or store each blob in a separate file referenced from the > database? I'm not totally sure. Quentin came up with a design back in 2008 where CoreObject is divided in to two components: - files storing the actual object contents - a discardable SQL database which acts as an index to the files, speeding up access / search. In the original implementation it was called COMetadataServer. Quentin's argument was that the storing the object content blobs in a SQL db doesn't take advantage of a SQL db's benefits, and the cost the cost of this is having a more complex on-disk storage format and more potential for corruption (even if sqlite is really well tested). I think I agree with this analysis. Do you have any preference with either way? Regards, Eric _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
