[jira] [Resolved] (FELIX-5326) Add data structure descriptor

["David Leangen (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/FELIX-5326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Leangen resolved FELIX-5326.
----------------------------------
    Resolution: Duplicate

> Add data structure descriptor
> -----------------------------
>
>                 Key: FELIX-5326
>                 URL: https://issues.apache.org/jira/browse/FELIX-5326
>             Project: Felix
>          Issue Type: New Feature
>          Components: Converter
>            Reporter: David Leangen
>
> The Converter service does a lot of introspection and parsing of the DTO data structure. In many cases, a DTO is a very simple object structure. However, it can also be a very complex structure, too.
> According to my understanding of the objectives of the Converter, one important goal is to be able to persist data. The idea is that the DTO describes the data structure. Thus, it is the ideal way to ship the state of the system off to PersistenceLand.
> If we do buy into this vision, then we may be missing out on a few great opportunities here. When data gets persisted, we often need to understand the relationships between the embedded objects. Or, we may want to be able to create an index on the data. These are a few of the reasons why we would want to have some kind of x-ray vision on the data structure. Since we already go through all the trouble of parsing the data structure in order to convert it, and since this is ~95% of the work, it would be really nice to provide access to this information in order to easily link in services that require this intimate knowledge. Otherwise, all the parsing would have to be done over and over again for each service.
> I believe that it would only take a few methods to be able to leverage all the parsing work done by the Converter. I can think of:
>  DataTree Converter.toTree(DTO dto); // DataTre gives a tree view of the structure
>  Object tree.valueAt(DTO dto, String path); // Dot-separated path value within the tree structure
>  void tree.set(DTO dto, String path, Object value); // Set the value at the given location in the tree structure
>  void process(DTO dto, Consumer<?> function); // Visit each node for some kind of processing
> Those are just some examples. Perhaps a new API would be necessary, but my main point here is that since we are going through all this work of implementing a parser, this is the IDEAL time to create this type of view on the data.
> Also, one of the properties of DTOs is that the DTOs are really, in a way, nothing more than schema. Because of this, it should be (and is) trivial to convert to JSON, XML, YAML, or whatever. If the DTO *is* the data structure, then it should also be trivial to convert the type descriptor (or tree, or whatever) to some kind of schema, like JSON Schema, DTD, XML Schema, RDF…
> That fits well with one of the features of the Converter: codecs to convert
> to/from serialized types. RFC 215 defines two portable codecs: JSON and
> YAML but other implementations can add their own codecs too. We could do the same not just for the live data instance, but for the data schema as well. (Note that this schema generation is not required: we could decide only to implement the data tree structure, and have an outside process generate the scheme, but at least the data tree would enable this).
> I do understand that it is a step away from a simple “Converter”, but the parsing is essentially the same. Since the hard work is already being done, why not take advantage of it here? Even if this tree view ends up being a completely different service, the same code base could easily serve the two.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)