[dotNetRDF-develop] Proposed Deprecation of SQL Stores in future releases

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

Hi All

I wanted to make everyone aware that it is my intention to mark all the SQL 
Stores and their related classes as obsolete in the next release (0.4.0 
Beta) of dotNetRDF.  They will still be usable for the next few versions 
(most likely until the 0.5.x releases which will be late 2011 at the 
earliest) in their current forms. I am not necessarily going to remove SQL 
stores in their entirety but I would like to significantly restructure the 
existing code.  It is likely that I will start from scratch and just 
re-implement support as IGenericIOManager implementations.  It is very 
likely that the existing ISqlIOManager interface will be removed form the 
library completely.

I am not yet sure whether I will modify the actual database structure or 
not though if I do so I will provide upgrade mechanisms for pre-existing 
stores in some form.  One possibility which I am looking into is moving 
some of the hard work off onto the SQL server by making use of stored 
procedures instead of doing most things client side.  Another possible 
improvement is to virtualise the data returned to some degree so that 
actual values aren't retrieved from the database until explicitly needed 
which should give a boost to read speeds in some circumstances.

Despite this I would like to point out that I am introducing a couple of 
useful new features into the API that can benefit users of existing SQL 
Stores:
The ability to explicitly reference the default unnamed graph in SPARQL 
Query and Update using the URI <dotnetrdf:default-graph> (as requested by 
the iRingTools team) - this improvement applies to in-memory stores as 
wellAn SqlDataset - this is an implementation of a new abstraction layer 
which allows for querying out of memory data using the library's existing 
Leviathan SPARQL Engine.  This means that the contents of a SQL store need 
not be loaded into memory prior to querying them.  Query Performance is not 
as good as in-memory querying due to the overheads of going to and from the 
database but this is a trade off against not needing to use large amounts 
of RAM to realise the data in-memory prior to querying.Alongside the 
aforementioned I have been working on adding support for a number of new 
stores (both 3rd party and internally developed) which will provide a 
broader range of alternative stores to SQL stores should you wish to 
migrate from your existing SQL Stores.

If you have any questions/queries about this please let me know

Best Regards,

Rob Vesse