[ https://issues.apache.org/jira/browse/FELIX-5326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Bosschaert reassigned FELIX-5326: --------------------------------------- Assignee: David Bosschaert > 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 > Assignee: David Bosschaert > > 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)