Re: [Vala] sqlheavy?



On Mon, 2012-07-02 at 11:22 -0700, Eric Gregory wrote:
On Thu, Jun 21, 2012 at 9:44 AM, Jonas Kulla <nyocurio googlemail com>wrote:

I assume it's pretty up to date.


Sadly that's not the case, which is why we're in the process of removing
SQLHeavy from Geary.

I don't really understand this.  First, based on
http://redmine.yorba.org/issues/5034 it sounds like that's not the
primary reason.  If it were the issue, it would be trivial to resolve.
There isn't really anything that needs to be done to keep SQLHeavy up to
date, since SQLite isn't exactly exploding with new features.  If you
just want new tarballs released more regularly that's really not a
problem--I released one last time you guys requested it and I can do it
again.  The other option is that I can just add someone from Yorba to
the list of maintainers and you're welcome to make releases whenever you
want.  Removing the sqlheavy-gen-orm utility would make this even more
simple (and likely unnecessary), since it would remove the dependency on
libvala.

The text of that bug leads me to believe that the primary reason is that
"... it's not clear that it will ever support concurrent database access
from multiple threads...".  That's actually not completely true--you can
still create multiple Database objects pointed to the same file on disk
(just like in SQLite).  What is missing is a layer to have
SQLHeavy.Datbase automatically create multiple connections to a single
database in order to support concurrent queries transparently.  That's
not a matter of keeping things up to date, that's a *major* new feature
which has basically necessitated the creation of a whole new library
(http://code.google.com/p/bump) as well as a rewrite of the SQLHeavy
internals.

I would be disappointed to see Geary move away from SQLHeavy, but if you
have an alternative which works I certainly can't fault you for
migrating to it.  I think I need about a week of full-time work in order
to finish the database/connection split, and since I'm very busy at work
these days (plus other open source stuff) I don't know when I'll have
that kind of time.  Until I do, SQLHeavy is in basically the same
situation as SQLite, which isn't a problem for the majority of users
(including the software I created SQLHeavy for in the first place).


-Evan




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]