Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Component/s: None
    • Labels:
      None

      Description

      QName management currently uses Name Caches. This needs to be externalized to the datamodel implementation. The core system should have a generic way of representing QNames

        Activity

        Hide
        Vinayak Borkar added a comment -

        This is a complex issue and I think it would be beneficial to discuss its design on before I make changes.

        The tasks to be performed are as follows:

        1. Create a new interface called "DatamodelStaticInterface" – Every datamodel implementation would have an implementation of this interface.
        2. Currently atomic values are implemented as concrete classes. There is also a concrete implementation called AtomicValueFactory.
        The idea here is to create an interface called AtomicValueFactory and have the current AtomicValueFactory be a class that implements that interface and generates the classes that it currently generates. Going forward, we should move away from requiring atomic values implement any particular interface. Instead, we would have an interface say "AtomicValueManipulator" that implemnents all the interfaces that the engine requires to work correctly.

        For e.g., instead of o.getDMOKind(), we would call m.getDMOKind(o), where m is an implementation of the Manipulator interface. The instance of the manipulator interface would be obtained from the DatamodelStaticInterface. This allows datamodel implementers to use their own objects as long as they can discern them at the XQuery level.

        I am looking for more comments on the issue.

        Show
        Vinayak Borkar added a comment - This is a complex issue and I think it would be beneficial to discuss its design on before I make changes. The tasks to be performed are as follows: 1. Create a new interface called "DatamodelStaticInterface" – Every datamodel implementation would have an implementation of this interface. 2. Currently atomic values are implemented as concrete classes. There is also a concrete implementation called AtomicValueFactory. The idea here is to create an interface called AtomicValueFactory and have the current AtomicValueFactory be a class that implements that interface and generates the classes that it currently generates. Going forward, we should move away from requiring atomic values implement any particular interface. Instead, we would have an interface say "AtomicValueManipulator" that implemnents all the interfaces that the engine requires to work correctly. For e.g., instead of o.getDMOKind(), we would call m.getDMOKind(o), where m is an implementation of the Manipulator interface. The instance of the manipulator interface would be obtained from the DatamodelStaticInterface. This allows datamodel implementers to use their own objects as long as they can discern them at the XQuery level. I am looking for more comments on the issue.
        Hide
        Till Westmann added a comment -

        One of the issues could be that the Manipulator interface gets quite big, if it is the union of all AtomicValue sub-interfaces. So we might want to consider breaking it up.

        Another question would be how far the Manipulator interface would go. E.g. today we have direct access to the Duration value of the DurationValue class and we make some use of it to implement arithmetic operations efficiently.
        One solution would be to provide a similar method on the Manipulator interface and to implement the arithmetic operations for all DM implementations based on the Duration values. But for a DM representation that does not use Duration objects internally, it would be some evaluation overhead to create those.
        Another solution would be to also move the arithmetic operations into the manipulator interface, allowing for more efficiency, but also requiring more implementation effort for each DM implementation.

        Show
        Till Westmann added a comment - One of the issues could be that the Manipulator interface gets quite big, if it is the union of all AtomicValue sub-interfaces. So we might want to consider breaking it up. Another question would be how far the Manipulator interface would go. E.g. today we have direct access to the Duration value of the DurationValue class and we make some use of it to implement arithmetic operations efficiently. One solution would be to provide a similar method on the Manipulator interface and to implement the arithmetic operations for all DM implementations based on the Duration values. But for a DM representation that does not use Duration objects internally, it would be some evaluation overhead to create those. Another solution would be to also move the arithmetic operations into the manipulator interface, allowing for more efficiency, but also requiring more implementation effort for each DM implementation.
        Hide
        Vinayak Borkar added a comment -

        Good point. Let us break the Manipulator interfaces at the type boundaries.

        The types like durations/datetime etc bother me too. Its a pain in the butt to get right, and I am willing to make the assertion that there are a countable few who would be willing to do so. We could get them to explore ways of refactoring VXQuery to include their implementation.

        I think we will need a "meet-in-the-middle" approach – some types can be fully externalized and some types will be translated into VXQuery's representation. I think this is going to be an engineering decision.

        Strings/Numbers are on one side and Datetimes/durations are on the other. The hardest type to decide on is the QName – Its common enough that you want a really fast implementation, while not making too many assumptions about how it is implemented – That's the oxymoron.

        Show
        Vinayak Borkar added a comment - Good point. Let us break the Manipulator interfaces at the type boundaries. The types like durations/datetime etc bother me too. Its a pain in the butt to get right, and I am willing to make the assertion that there are a countable few who would be willing to do so. We could get them to explore ways of refactoring VXQuery to include their implementation. I think we will need a "meet-in-the-middle" approach – some types can be fully externalized and some types will be translated into VXQuery's representation. I think this is going to be an engineering decision. Strings/Numbers are on one side and Datetimes/durations are on the other. The hardest type to decide on is the QName – Its common enough that you want a really fast implementation, while not making too many assumptions about how it is implemented – That's the oxymoron.
        Hide
        Vinayak Borkar added a comment -

        This issue is no longer valid with the code overhaul.

        Show
        Vinayak Borkar added a comment - This issue is no longer valid with the code overhaul.

          People

          • Assignee:
            Vinayak Borkar
            Reporter:
            Vinayak Borkar
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development