Re: Re-opening ISSUE-22 on vendor-specific SQL

* David McNeil <dmcneil@revelytix.com> [2011-05-31 08:23-0500]
>  My current proposed solution for this is:
> 
> * by default SQL queries in R2RML are expected to be SQL 2008 compliant.
> 
> * SQL queries that make use of vendor specific SQL constructs are flagged as
> "vendor specific". To support validation, vendor specific queries can
> include a property in the mapping that defines the names of the columns
> projected by the query.
> 
> I don't feel a need to try and identify what vendor the SQL complies with in
> these cases, but merely that it is vendor specific.
> 
> This solution fits well with a use-case in which most of the queries are
> standard but a few use vendor specific constructs. Most of the queries can
> be parsed by the R2RML implementation (this is useful for validation and
> optimization). The few queries with vendor specific constructs can be simply
> passed through to the database engine as "opaque" queries. Using this
> approach in conjunction with an eventual (post R2RML 1.0) solution for SQL
> composition in the mapping allows the mapper to isolate vendor specific SQL
> in small, reusable queries and keep the bulk of the SQL in SQL 2008
> compliant queries.

Since we're creating a new property (to flag vendor specific queries)
anyways, we can say that the object of that property is an identifier
for the embedded language:

_:someTriplesMap
    rr:languageId <http://oracle.example/OracleSQL10> ;
    rr:SQLQuery """SELECT ('Department' || deptno) AS deptId …""" .

People can use these IDs to know which languages they can optimize,
e.g. the Revelytix implementation knows that it parses <…/OracleSQL10>
and <…/OracleSQL11>. When users don't see a return on digging up an
identifier for the language, they can just stipulate that there is one:

_:someTriplesMap
    rr:languageId _:noneOfYourBusiness ;
    rr:SQLQuery """SELECT ('Department' || deptno) AS deptId …""" .

and forgo the clever optimizations that the R2RML engine might be able
to offer them.


> -David

-- 
-ericP

Received on Tuesday, 31 May 2011 13:49:26 UTC