[ 
https://issues.apache.org/jira/browse/FELIX-5326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15504984#comment-15504984
 ] 

David Leangen commented on FELIX-5326:
--------------------------------------

Closing, as this is essentially a duplication of [FELIX-5332].

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

Reply via email to