[
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)
