[Monodevelop-devel] Using SQLite as parser database
christian.hergert at gmail.com
Mon Jul 28 18:08:36 EDT 2008
On Mon, Jul 28, 2008 at 2:44 PM, Mike Krüger <mkrueger at novell.com> wrote:
>> This discussion should have been done before committing anything to
>> trunk, but here it is anyway.
>> Migrating to SQLite only makes sense if it provides noticeable
>> improvements in performance and memory use. Guessing that it will be
>> better is not enough. We need real numbers before taking the decision
>> switch, and only do it if the numbers are so much better that pay off
>> the burden of having a dependency on SQLite.
>> I might be wrong, but I don't believe that SQLite will be better than
>> the ad-hoc database we are using in MD 1.0. I spent a lot of time
>> up the parser database, and I'm quite happy about how is it
> Some more benefits for using a real database over an own implementation:
> - It's reliable. Atomic transactions, threading - all solved.
While I'm happy with either solution, lets keep in mind that sqlite is
not thread-safe by default (requires SQLITE_THREADSAFE=1 at compile
time). So we will need to queue queries via a single-thread unless we
can guarantee our sqlite version.
Perhaps the sqlite wrappers take care of that now, I really haven't checked.
> - It's easy to look into the data using a command line client and SQL
> Its not just pure performance. Using a database will allow us for
> example to switch the database software to a new implementation. And
> databases and SQL are very easy to understood and to change.
> I had to think about it too (I implemented the #develop database some
> years ago which monodevelop inherited (but optimized I admit ^^)) -
> after thinking about it the decision was easy - A database makes it
> easier to change the model and to make complicated querys more
> There are many more reasons using database software instead of own data
> storage solutions - otherwise the whole database software would be
> Monodevelop-devel-list mailing list
> Monodevelop-devel-list at lists.ximian.com
More information about the Monodevelop-devel-list