Re: GSoC Weekly Report

["Joe Shaw" <joe joeshaw org>]

Hi,

On 10/16/07, D Bera <dbera web gmail com> wrote:
> A followup question, I didnot find any API documentation of
> Mono.Data.Sqlite :( #mono was also sleeping when I asked the question
> there.

My understanding is that both M.D.SqliteClient and M.D.Sqlite follow
the general ADO.Net API patterns and that the latter is more or less a
drop-in replacement for the former.  A few things may need to be
tweaked, but in general just changing the "using" statements at the
top of each source file should be all that's needed.

> If M.D.Sqlite does not have a way to return rows on demand, I
> am against the migration. In the worst case, we can ship with a
> modified copy of M.D.Sqlite but I am not sure what will that buy us.

You've always been able to get rows on demand via ADO.Net, it's just a
matter of the implementation underneath.  The old one (not modified by
us) would load all of them into memory.  I'm not sure how the new one
performs memory-wise.  If the Mono guys don't have any idea, the right
thing to do here would be to create a large test database (or use an
existing TextCache or FAStore db) and do a "SELECT *" using the 3
implementations and walk the results, using heap-buddy and/or
heap-shot to analyze their memory usage.

> In the same breath, what is the benefit of M.D.Sqlite over
> M.D.SqliteClient for beagle ? I figured out there are some ADO.Net
> advantages but other than that ... ?

It's maintained for one, which our modified one essentially isn't.  It
has the backing of the Mono team.  The code is much cleaner and easier
to understand, largely because it doesn't have two separate codepaths
(one for v2 and one for v3).  I am sure the Mono guys have other good
reasons too. :)

Joe