subjects used as predicates don't have iris in query results

[dpetran]

If a subject is created in one transaction and then used as a predicate in another transaction, the query will fail to translate the predicate id into an iri.

(let [conn   @(fluree/connect {:method :memory})
        ledger @(fluree/create conn "propertypathstest" {:defaultContext [test-utils/default-str-context {"ex" "http://example.com/"}]})
        db0    (fluree/db ledger)
        db1    @(fluree/stage db0 [{"@id" "ex:preexisting-pred"
                                     "ex:description" "created as a subject first"}])
        db2 @(fluree/stage db1 [{"@id" "ex:subject-as-predicate"
                                     "ex:preexisting-pred" "foo"
                                     "ex:new-pred" "bar"}])]
  @(fluree/query db2 {"select" {"?s" ["*"]}
                                   "where" [["?s" "@id" "ex:subject-as-predicate"]]}))
;; actual
{"id" "ex:subject-as-predicate",
 "ex:new-pred" "bar",
  211106232532992 "foo"}
;; expected
{"id" "ex:subject-as-predicate",
 "ex:new-pred" "bar",
 "ex:preexisting-pred" "foo"}

[dpetran]

This is due to how we find vocab flakes. On each transaction we check the new flakes for vocab flakes. That is done by checking if any new flakes have a subject in the "predicate" range. A subject that is created without being used as a predicate is assigned a subject id in the general "subject" range, and so it doesn't trigger a vocab/refresh-schema call.

We need some sort of general way of telling when we have new vocabulary that won't degrade performance, since we do this vocabulary check in a lot of places.

[dpetran]

We do have a workaround in the case where we know/suspect a given iri will be used as a predicate in the future. In those cases we can add the predefined pid to the fluree.db.json-ld.ledger/generate-new-sid function. It's not a general solution though and something more robust is necessary to handle unexpected subjects-as-predicates.

[aaj3f]

For additional context: https://fluree-internal.slack.com/archives/C04AA19P3FW/p1692392282856609

[aaj3f]

Moved to top of backlog as it impacts integration of FlureeSense data output into v3

[aaj3f]

@dpetran -- just want to confirm that you saw this message in Slack

Before we close this, I just want to confirm that this behavior (at least against http-api-gateway) is still seeing properties that are inserted via nested JSON-LD are still returning integers instead of IRIs in query results