search

fluree / core

Fluree releases and public bug reports
0 stars 0 forks source link

IRIs that appear to have prefixed terms (but do not) are unusable in queries #59

Closed aaj3f closed 7 months ago

aaj3f commented 7 months ago

Description

When an IRI like ex:Yeti or ex:freddy or ex:name is used in a query, but ex is not a term defined in the context, Fluree currently fails to treat the value as an "already expanded" value in query execution.

For example, if I add data like { "@id": "ex:andrew", "ex:name": "Andrew" } but I don't have a term defined for ex in my context, Fluree just commits this as an unexpanded value (e.g. ex:andrew instead of, obviously, http://example.org/andrew). That's all fine and correct.

BUT, if I then go to query for that (e.g. where: { "@id": "?s", "ex:name": "?name" }), and if I have any @context for Fluree to use to do a failing lookup of ex, then I get [] results. The only way I can query it is if I explicitly set @context: null in the query.

Likely what is happening is that Fluree's query processing says "oh... they used a term ex, let me try to expand that... oh wait I can't..." but then instead of trying to use ex:name as a literal value for an IRI, it just seems to not do a lookup on it at all

TLDR if any entity or property is identified as simply ex:andrew or foobar:andrew, where that ex isn't used as a context-defined term, then queries that use those IRIs as is for their lookups

Note: there is a possibly related bug item that I'm going to include here. If I add an entity with a very simple @id value (e.g. "@id": "freddy"), then I am unable to issue this query with select and not where:

{
  "from": "test-ledger",
  "select": { "freddy": ["*"] }
}

Whereas, if I add the entity as "@id": "http://example.org/freddy", then I am able to do

{
  "from": "test-ledger",
  "select": { "http://example.org/freddy": ["*"] }
}
cap10morgan commented 7 months ago

@aaj3f I have been unable to reproduce either of these bugs on the latest main HEAD of db (currently 5d4acbd64c1af6c6032619f9b527b5bcf67c7bd0).

aaj3f commented 7 months ago

@cap10morgan -- huh... we fixed it! Yes sorry when I was using main HEAD of server (with whatever dep on db it had), this was buggy, but updating the db dep to db's main HEAD fixed it!

Sorry to send you on a goose chase!

cap10morgan commented 7 months ago

@aaj3f All good! I love it when we already fixed a bug! :)