GNOME Bugzilla – Bug 568787
Port to Mono.Data.Sqlite
Last modified: 2009-02-02 23:45:35 UTC
Bug with threading in M.D.S appears to have been fixed, so it should be used to take advantage of advanced features such as custom functions and prepared statements.
Created attachment 127148 [details] [review] Port to Mono.Data.Sqlite Two sources of errors I've encountered: * m.d.sc.SqliteDataReader slurps the entire result set into memory when it's constructed. Banshee relies on the result set being closed by the time the reader is constructed, so I've written a small wrapper to the new m.d.s datareader class that emulates the old behavior. It reuses much of the code from the old datareader, and seems to be working, but it needs a good going-over by somebody familiar with ADO.NET. * There are places in the code that cast database columns to (int), such as DatabaseTrackInfo.TrackEqual(). Integers are apparently returned as instances of System.Int64 now, so those casts should be changed to (long).
How is this working for you, John? Any errors whatsoever? Can you use --debug-sql to compare performance of some key commands with and without your patch? Great job figuring out that SC slurped the whole result into memory - I was completely unaware, though it makes perfect sense now. No wonder we can access its results from any thread. :) Your patch is looking really good - very simple. Change the HyenaSqliteArrayDataReader class to be internal, and add a comment near the top explaining where this code came from, why it's in Hyena, and any changes we've made.
No errors for me, including a complete import of my library, playing tracks, and messing about with playlists. What key commands do you mean? I didn't notice any difference in performance, but if there are some queries known to run slowly I can watch for them.
Created attachment 127368 [details] [review] Port to Mono.Data.Sqlite (v2) Updated patch. Fixes another cast from SqliteDataReader to IDataReader, sets array-based datareader to "internal", and adds explanatory comment. > Can you use --debug-sql to compare performance of some key commands with and > without your patch? I've compared every feature that needs lots of time I could, and don't see any performance degradation. Are there are any particularly slow commands you'd like checked?
Awesome, great job on this, John: committed!
Not sure why I didn't close this before; closing.