Error querying virtual graphs when SQL accessed complex type in Athena

Support
1

I'm trying to leverage AWS Athena's support for querying complex types in a virtual graph mapping, but I am not having much luck.

For example, if I create a table using the AWS docs for flattening arrays using the following query

CREATE TABLE IF NOT EXISTS people
  WITH (format='PARQUET', external_location='s3://maze-personal/nnichols/stardog-test') AS
SELECT ARRAY[
   MAP(ARRAY['first', 'last', 'age'],ARRAY['Bob', 'Smith', '40']),
   MAP(ARRAY['first', 'last', 'age'],ARRAY['Jane', 'Doe', '30']),
   MAP(ARRAY['first', 'last', 'age'],ARRAY['Billy', 'Smith', '8'])
] AS people

I am able to query the table using the following

SELECT 
  names['first'] AS first_name,
  names['last'] AS last_name
FROM people
CROSS JOIN UNNEST(people) AS t(names)

This returns a table that I would like to use in a virtual mapping like so

MAPPING
FROM SQL {
  SELECT 
    names['first'] AS first_name,
    names['last'] AS last_name
  FROM "default"."people"
  CROSS JOIN UNNEST(people) AS t(names)
}
TO {
  ?subject rdf:type :people .
} WHERE {
  BIND(template("people{first_name}") AS ?subject)
}

I am able to save this mapping, but when I try to query the mapping with

SELECT *
FROM <virtual://unnest-test>
WHERE {
  ?subject rdf:type :people .
}

But I get the following error in the console

Failed to run query: com.complexible.stardog.plan.eval.ExecutionException: Unexpected RelNode class: LogicalCorrelate

I've run into similar issues when trying to use SQL with a presto/athena dialect to access arrays, maps, etc, but as far as I can tell Calcite supports this.

Is this a known issue or am I missing something? Help much appreciated!

2

I think I found a work around for this issue where I can create a view that flattens out any complex types and then create my virtual graph by querying the view.

While this works, I would still expect any valid Athena query executed within a virtual graph mapping to run successfully.

Is my assumption that complex SQL queries should work in virtual graph mappings correct or are the SQL queries that go into a virtual graph expected to be fairly simple?

3

Hi Nolan,

As you discovered, Stardog doesn't support complex types. The view approach that you went with is a good workaround, though you may find the SQL that Stardog generates can be inefficient (too many inner joins) if the database doesn't advertise what columns in the view are unique. You can address that by setting the unique.key.sets property. The queries in the mappings are allowed to be arbitrarily complex, but during the SPARQL to SQL translation each triple pattern that maps to that query will create a join. Stardog will do its best to simplify and reduce the joins, but the more complicated it gets the greater the chance that large SPARQL queries will translate to even larger SQL queries, so best to use with care.

-Paul