tomdroid-dev team mailing list archive
Mailing list archive
Re: [tomboy-list] tomdroid's storage-redesign && what do we want to keep in the database as a note?
Sorry for reviving an old thread. Take notice that I took the tomboy list
out to avoid spamming them (and Sandy is on tomdroid list).
On Wed, Nov 18, 2009 at 3:42 AM, Cornelius Hald <hald@xxxxxxxxx> wrote:
> So what I'm doing is storing the <note-content> subtree as string in a
> member of each Note object. When showing a note only this subtree is
> parsed and displayed. When saving a note object to the database we only
> store this subtree in the database as xml, the metadata is saved
> When saving to a xml file, the rest of the file is constructed and the
> <note-content> subtree is merged with it.
Do you keep <note-content> or discard it? Right now I'm keeping it because
the parser doesn't throw an exception that way.
> For me the problem was the parsing of the <note-content> sub tree,
> because it has no namespace definitions after extracting it from the
> main document. They are only available on the <note> element and libxml
> throws an error if you try to parse an element like <size:big> without
> having a reference to the "size" namespace.
Yes, had the same problem with SAX but I was able to work-around it, turns
out there are options for that but it took me a little while to figure that
> For your solution #1 I don't see a big problem there. Only you need to
> decide which metadata is the "correct" one. The one in the database or
> the one on in the xml document. It's not really nice to store redundant
> data, but in this case it's probably not too bad and the extra cost of
> parsing through the metadata shoudn't be that big.
After reading your reply and Sandy's I decided to forget about keeping the
whole note. The big argument was that the REST call was giving me only the
> About solution #2. Well, I think we all know that using regexp on xml is
> not the right thing (tm) to do. But I don't see a big problem in this
> case as the structure of those documents is well know and there
> shouldn't be any surprises. In fact I'm doing some regexp suff on xml in
> my code as well. Not proud of it, be it works ;)
Well, your regexp is probably pretty tight and, anyways, we all have to get
pragmatic sometimes. Conboy is definitely something you can be proud of.
Nice job with the website by the way! Awesome! (others, check this out:
> BTW, does using a database for storage really improves speed for you?
Android's default "userspace" storage is the sdcard and it's kinda slowish.
Maybe I was doing something wrong but at each start I was going through the
notes to load them in memory (to grab the titles and generate the
appropriate wiki-links) and for my note collection (~60 notes) it's quite
slow for a phone app, like 4, 5 seconds.
With the database doing that portion is instant (well in the subsecond) but
I haven't officially benchmarked yet.
> I'm just asking because I had no performance issues so far. But only
> tested with around 100 ntoes. I can load them in about 1 second on the
> Nokia N810 which is a quite slow device. But your results would really
> interest me.
I took some benchmarks of my previous work trying to get the multi-threading
right, I captured the results to this file in our bazaar repo:
> Are you using sqlite or something else?
Yes, sqlite. Android provides an API to easily deal with sqlite databases.
It's quite nicely integrated actually and I think it's what most developers
have been doing.
By the way, I just want to give a shoutout to Benoît since it's because of
his good work that we are talking about the performance gains on databases.
He did all the work! All I did was complain about some things with his code
Keep up the good work Cornelius!
Olivier Bilodeau <olivier@xxxxxxxxxxxxxxxxx>