OpenEngSB
  1. OpenEngSB
  2. OPENENGSB-3602

Provide additional method in OpenEngSBModel which returns only the properties of the object itself

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: openengsb-3.0.0.M1
    • Component/s: framework
    • Labels:
      None
    • Changelog:
      added new method toOpenEngSBModelValues which returns the model entries without the elements in the model tail.

      Description

      Until now there are only the methods getOpenEngSBModelEntries and getOpenEngSBModelTail. The first method also contains the values of the tail. But there should be a method that return the entries without the tail entries.

        Gliffy Diagrams

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

          Hide
          Thomas Rausch added a comment -

          I think the way toOpenEngSBModelEntries, addOpenEngSBModelEntry, getOpenEngSBModelTail work is a little untransparent and unpractical for developers.

          Maybe we can consolidate them into something more intuitive like

          • getModelEntries returns ALL entries (values, meta data, and those added with addOpenEngSBModelEntry)
          • getModelValues returns only the properties of the defining @Model annotated class
          • getModelMetaData returns only the models meta-data (ebdVersion, modelType, edbTimestamp, ...)

          WDYT?

          Show
          Thomas Rausch added a comment - I think the way toOpenEngSBModelEntries , addOpenEngSBModelEntry , getOpenEngSBModelTail work is a little untransparent and unpractical for developers. Maybe we can consolidate them into something more intuitive like getModelEntries returns ALL entries (values, meta data, and those added with addOpenEngSBModelEntry ) getModelValues returns only the properties of the defining @Model annotated class getModelMetaData returns only the models meta-data (ebdVersion, modelType, edbTimestamp, ...) WDYT?
          Hide
          Thomas Rausch added a comment -

          BTW: is there a way easily get all currently existing meta-data property names? i know there's the EDBConstants, but as far as i can see the list is incomplete

          Show
          Thomas Rausch added a comment - BTW: is there a way easily get all currently existing meta-data property names? i know there's the EDBConstants , but as far as i can see the list is incomplete
          Hide
          Felix Mayerhuber added a comment -

          Since there is no definition what is meta data and what is a normal tail element (cause they are conceptually the same), it is quite hard to create the getModelMetaData. What is easily possible for now is to make:
          getModelEntries
          getModelValues
          getModelTail
          and it makes definitely sense to create these functions!
          But in the long run, I think it would be better to change this with the meta data in general. I think it would be better to add additional fields/methods to the enhanced model classes and access them directly. To use the model tail was easy, but I think it is not really practicable. Also it would definitely make sense to save this meta data in the model itself and not somewhere with some generic key in a list.

          WDYT?

          Show
          Felix Mayerhuber added a comment - Since there is no definition what is meta data and what is a normal tail element (cause they are conceptually the same), it is quite hard to create the getModelMetaData. What is easily possible for now is to make: getModelEntries getModelValues getModelTail and it makes definitely sense to create these functions! But in the long run, I think it would be better to change this with the meta data in general. I think it would be better to add additional fields/methods to the enhanced model classes and access them directly. To use the model tail was easy, but I think it is not really practicable. Also it would definitely make sense to save this meta data in the model itself and not somewhere with some generic key in a list. WDYT?
          Hide
          Thomas Rausch added a comment -

          while i see where you're coming from, when you say that they're conceptually the same, from a developer standpoint i think the distinction is fairly clear: all attributes that are not declared by @Model annotated class, are meta data. actually i think that makes perfect sense, seeing as attributes such as commit timestamp, oid, model version, etc. all lie above the model definition (i.e. come from the OpenEngSBModel interface).

          if you think this breaks your concept, of course i will not try to force it in, but i think we need a cleaner documentation/definition of what the methods do that are in place now.

          specifically MSe needs to fetch all OpenEngSBModelEntries, which are attributes defined by the model class, and omit all other attributes (commit timestamp, model version, ...), which does not seem to work as he expects.

          Show
          Thomas Rausch added a comment - while i see where you're coming from, when you say that they're conceptually the same, from a developer standpoint i think the distinction is fairly clear: all attributes that are not declared by @Model annotated class, are meta data. actually i think that makes perfect sense, seeing as attributes such as commit timestamp, oid, model version, etc. all lie above the model definition (i.e. come from the OpenEngSBModel interface). if you think this breaks your concept, of course i will not try to force it in, but i think we need a cleaner documentation/definition of what the methods do that are in place now. specifically MSe needs to fetch all OpenEngSBModelEntries, which are attributes defined by the model class, and omit all other attributes (commit timestamp, model version, ...), which does not seem to work as he expects.
          Hide
          Felix Mayerhuber added a comment -

          The problem is, that not everything that is in the tail is only meta data, at least it does not need to be the case. This is the case because everyone can add new OpenEngSBModelEntries to the tail completely independent from the fields of the model. If you want to, you can add a complete separate object into the model tail : )

          But I think we are confusing each other ^^ I'm completely on your opinion that there should be an own method that returns you only the model entries which are representing the fields of the specific model. To be exact, that was the idea of the issue in the first place. The things I've said in the last comment go one step further:

          I would say there should be an own method for retrieving only the model entries, one for retrieving the model tail entries and one for retrieving both. And additionally I want to move the "meta-data" (timestamp, model version, ...) into fields of the model itself (which are added by the enhancer) so that they are independent of the tail concept. TBH I don't really know if we need the tail concept at all (also Andi has that opinion as far as I know). So this would be the next step to remove the tail concept and get a cleaner model handling.

          So I would say we first make the step, that we create the three methods I mentioned before (should be a work of a few minutes, since the methods we need for that are already present in the enhancement) and make a new issue for the "meta-data" extraction from the tail to the model.

          WDYT?

          Show
          Felix Mayerhuber added a comment - The problem is, that not everything that is in the tail is only meta data, at least it does not need to be the case. This is the case because everyone can add new OpenEngSBModelEntries to the tail completely independent from the fields of the model. If you want to, you can add a complete separate object into the model tail : ) But I think we are confusing each other ^^ I'm completely on your opinion that there should be an own method that returns you only the model entries which are representing the fields of the specific model. To be exact, that was the idea of the issue in the first place. The things I've said in the last comment go one step further: I would say there should be an own method for retrieving only the model entries, one for retrieving the model tail entries and one for retrieving both. And additionally I want to move the "meta-data" (timestamp, model version, ...) into fields of the model itself (which are added by the enhancer) so that they are independent of the tail concept. TBH I don't really know if we need the tail concept at all (also Andi has that opinion as far as I know). So this would be the next step to remove the tail concept and get a cleaner model handling. So I would say we first make the step, that we create the three methods I mentioned before (should be a work of a few minutes, since the methods we need for that are already present in the enhancement) and make a new issue for the "meta-data" extraction from the tail to the model. WDYT?

            People

            • Assignee:
              Felix Mayerhuber
              Reporter:
              Felix Mayerhuber
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: