Virtual graph import NPE

Support Bug
1

Stardog 5.2.0

I’m getting a NPE when importing a virtual graph from mysql.

java.lang.NullPointerException at com.complexible.stardog.virttual.VirtualGraphIterator$MaterializationContext.getColumnIndex(VirtualGraphIterator.java:281)

…

An error occurred adding RDF to the index: null

I’m sorry that I can’t include the mappings, data or complete stack trace but I thought I’d report it anyway.

2

Thanks. Do you have any quoted field names, eg `field with space`? We did some work that may have fixed this in 5.2.1. Worth trying. The error message has been improved to indicate which field was not found which may help narrow down the issue.

Jess

3

No quoted fields but I think I found out what the problem was. I was doing a join between two tables (actually a self join) and using the table alias in the mapping since there were duplicate column names. If I alias the columns and don't use the table alias it seems to work. This isn't the exact mapping but just a quick example.

The following doesn't work

<{a.id}> a my:Thing
:has <{b.id}>
sm:map [
sm:query """
select
a.id,
b.id
from
mytable a
join
mytable b
on
a.id = b.otherid"""
] .

while this does

<{a_id}> a my:Thing
     :has <{b_id}>
sm:map [
  sm:query """
      select
        a.id as a_id,
        b.id as b_id
      from
         mytable a
      join
         mytable b
      on
      a.id = b.otherid"""
] .

Hopefully I captured that correctly.

4

Thanks a lot for the illustration. I’ll dig into it. This is really helpful.

Jess

5

Glad to be helpful. Quick follow up for you and anyone following.

It appears that aliasing one of the tables isn't sufficient. (I wasn't debugging but being lazy and seeing if I could save myself some typing :wink:

So based on the example I gave the following wouldn't work either

<{a_id}> a my:Thing
     :has <{b.id}>
sm:map [
  sm:query """
      select
        a.id as a_id,
        b.id
      from
         mytable a
      join
         mytable b
      on
      a.id = b.otherid"""
] .
6

I think this would work with a query but not with materialization (or ?s ?p ?o query). We treat the field names literally during materialization but I guess we need to generate a better projection to properly resolve the fields and avoid any ambiguities.