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

Hi David,

On 31 May 2011, at 14:23, David McNeil wrote:
> 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.

Hm … the names of the columns is already implied in the rest of the TriplesMap(s) that are using the query as its logical table. I'd be concerned about repeating this information onece more in a new property.

> 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.

Devil's advocate: Just try to parse it as SQL 2008; if that fails, it's vendor-specific?

A problem I see is that the average mapping author may not be aware of the differences between SQL 2008 and the SQL dialect they use. So they would have trouble if asked to indicate which queries are vendor specific and which are not.

Best,
Richard


> 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.
> 
> -David

Received on Tuesday, 31 May 2011 14:06:07 UTC