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
|