1. Summary
  2. Files
  3. Support
  4. Report Spam
  5. Create account
  6. Log in

Ticket #373 (closed defect: fixed)

Opened 21 months ago

Last modified 19 months ago

Fix StrBOp and other IValueExpressions

Reported by: mrpersonick Owned by: thompsonbry
Priority: critical Milestone:
Component: Bigdata RDF Database Version: TERMS_REFACTOR_BRANCH
Keywords: bop, value expression, materialization, dummy IV Cc: mrpersonick, thompsonbry, mroycsi

Description

Certain value expressions that are currently INeedsMaterialization.ALWAYS can probably be changed to work with inline values now that bops implement the openrdf Value interfaces. A good example of this is StrBOp, which uses the Literal.getLabel() method to do its work. Currently, it calls bop.getValue().getLabel(), which can result in NotMaterializedExceptions?. By simply tweaking it to use bop.getLabel(), StrBOp can operate on fully inline values (except for extensions) without resorting to costly materialization. This will allow it to work on bops that were created by other value expressions but that do not exist in the database. For example, right now, it would not be possible to evaluate this:

StrBOp(MathBOp(?x+1))

Because the result of the MathBOp will be an inline numeric, and even if ?x is materialized, (?x+1) will not be. This is an example of a "dummy inline IV".

There are also value expressions that can create dummy non-inline IVs, such as the DatatypeBOp or any other value expression that returns a URI. However this will never be a materialization problem, since these dummy non-inline IVs are by their very nature already materialized.

Change History

Changed 21 months ago by mrpersonick

  • status changed from new to assigned

Changed 21 months ago by thompsonbry

  • cc mroycsi added
  • priority changed from major to critical

Changed 21 months ago by thompsonbry

  • status changed from assigned to accepted

Mike,

Can you comment on the performance tradeoffs of always doing iv.getLabel() when we could have done native operations on the IV's inline numeric datatype? It seems to me that materializing the label:String, then parsing it and creating a Literal from that would be quite wasteful when we already know how to handle the inline numeric IV. So, while this works for ALWAYS, we would not want to propagate this change to bops which can operate on inline IVs, right?

Bryan

Changed 21 months ago by mrpersonick

You would want to avoid situations like that, but for the most part, this is a non-issue. For example, Sesame's compare operation does not use getLabel() for numerics, it uses the methods like booleanValue(), decimalValue(), doubleValue(), etc.

Changed 19 months ago by mrpersonick

  • status changed from accepted to closed
  • resolution set to fixed

From inspection it looks like we are pretty much in the clear on this now. Still need to be mindful with future bops.

Note: See TracTickets for help on using tickets.