Little to report. This week has been substantially dedicated to work on the Development Support Framework, but earlier in the week I did spend some time refactoring parts of Omneity’s data layer.
The main changes are to the way clients access the underlying database. Rather than direct access through the interface of the DataSourceManagerImpl clients will use a Connection provided by the DataSourceManagerImpl in response to a connect()—so DataSourceManagerImpl acts as a Connection factory.
These Connection objects then take objects offering the Statement interface (created directly using, for example, SPARQLQuery or GremlinStatement, or indirectly using a Statement builder like SPARQLBuilder or GremlinBuilder). The Connection object offers execute() methods that operate on these Statement objects to query or update the underlying data source.
This approach is significantly cleaner as it decouples implementation details from the DataSourceManagerImpl and abstracts them through Connection objects.
The upshot of all this is that, theoretically, the underlying data sources (database and Adapters) can be replaced without consequence to the client code. It also means that Connections act as scope limiters on the underlying data, allowing client code to query data within the scope of an Adapters Connection rather than the global scope of the agent’s local database.
The one ‘trick’ necessary to make life easier on Adapter writers it that Connections returned are proxies for underlying Adapters. The scope limitation is performed by the DataSouceManagerImpl, not the Adapter. This saves the Adapter from having to write special code to handle what are essentially database queries.