[dotNetRDF-Support] Advanced Notice - Deprecating our SQL Backend

[Rob V. <rv...@do...>]

Hi All

For those who've been using the project for a long time you'll be aware that
once upon a time our only persistence mechanism other than writing RDF to
disk was a SQL backend.  Over time we've introduced support for a variety of
great open source and commercial triple stores as backends and our SQL
backend has languished in obscurity because we've been far more focused on
building a solid general purpose RDF and SPARQL API and not on trying to
build our own triple store (which has always been a stated aim of the
project ­ build an API not a triple store).

With this in mind and in view of the performance and scalability numbers I
and others have been presenting at the SemTechBiz [1] conference here in San
Francisco it's clear to me that our SQL backend is never going to compete
with (not that it was ever designed to).  With this in mind I have decided
that I personally am going to stop any further work on this and stop
supporting this feature after the upcoming 0.7.x releases.  In particular I
intend to remove this from both the SVN trunk and standard release package
after those releases.

Note that the SQL backend uses the same API (IGenericIOManager) as all the
other triple stores we support so it should be relatively easy for people to
migrate off of the SQL backend.  On a slightly unrelated note the
IGenericIOManager API is getting some renaming in the 0.7.x releases but all
changes are fully backwards compatible in the short term.

Please see [2] for a blog post which discusses more of the reasoning behind
this.  As I note in the post there this is up for discussion as for
everything else but if you really want this to be improved and be continued
to be maintained then you need to step up and volunteer.  My time is limited
and I would rather focus on the areas where I have the knowledge and
expertise to improve the performance and stability of the Core APIs rather
than focus on off things that are already handled better by other features
of the API.

Rob Vesse