Stardog server 5.0.5
jdbc driver: sqljdbc42-6.0.8112.100.jar
ObjectId, VersieId, GemeenteStatus,
WHERE Gemeentenaam.GemeenteObjectId = Gemeente.ObjectId and Gemeentenaam.Taal=‘nl’
) AS Gemeentenaam_NDL,
WHERE Gemeentenaam.GemeenteObjectId = Gemeente.ObjectId and Gemeentenaam.Taal=‘fr’
) AS Gemeentenaam_FRA,
WHERE Gemeentenaam.GemeenteObjectId = Gemeente.ObjectId and Gemeentenaam.Taal=‘de’
) AS Gemeentenaam_DEU
Getting as error:
field [Gemeentenaam_NDL] not found; input fields are: [ObjectId, VersieId, GemeenteStatus, $f0, $f00, $f05] term map=COLUMN(Gemeentenaam_NDL)@nl field [Gemeentenaam_FRA] not found; input fields are: [ObjectId, VersieId, GemeenteStatus, $f0, $f00, $f05] term map=COLUMN(Gemeentenaam_FRA)@fr field [Gemeentenaam_DEU] not found; input fields are: [ObjectId, VersieId, GemeenteStatus, $f0, $f00, $f05] term map=COLUMN(Gemeentenaam_DEU)@de
Hi Paul. Will get back to you on these Wednesday.
I suppose that in the past the query in the R2RML was sent as such to the SQL endpoint including non-standard SQL dialect features proper to the database used.
I have the impression that now the SQL used needs to be in the by Apache Calcite supported SQL variant and shockes on non standard language.
virtual import we always send the query verbatim from the mapping. In contrast, SPARQL queries over the federated virtual graph currently require the SQL query to be parsed. We’re planning to relax this at the cost of some optimizations. The operators used in your other post, bitwise NOT (
~) and bitwise XOR (
^), are not recognized by the SQL grammar. While we support custom functions (via
sql.functions), we aren’t able to do this with operators.
The query in this post is parsed but there’s a bug in our treatment of it whereby we aren’t able to reference the subquery fields. I have created issue #4481 for this and we’ll get it fixed in the December or January release.
Thank you very much for this clarification.
I wanted to close the loop with respect to issue #4481 that Jess mentioned. This was included in release 5.1, which released today. Please give it a try at your convenience and let us know how it works out.
Just tested this,
but get now
An error occurred adding RDF to the index: 'SINGLE_VALUE' is not a recognized built-in function name.
We’ve been able to recreate this error. I have created issue #4545 for it.
The issue is that Calcite converted the subquery into a join and, because it wasn’t able to guarantee it would return a single row, inserted this SINGLE_VALUE function, which isn’t supported on MS Sql. The test I ran when testing the last fix had a max() operator around the returned value of the subquery, so I missed this problem.
I’ll update you when we have a fix.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.