Details

      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.

        Activity

        Hide
        bryanthompson bryanthompson added a comment -

        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

        Show
        bryanthompson bryanthompson added a comment - 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
        Hide
        mikepersonick mikepersonick added a comment -

        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.

        Show
        mikepersonick mikepersonick added a comment - 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.
        Hide
        mikepersonick mikepersonick added a comment -

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

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

          People

          • Assignee:
            bryanthompson bryanthompson
            Reporter:
            mikepersonick mikepersonick
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: