felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Leangen (JIRA)" <j...@apache.org>
Subject [jira] [Created] (FELIX-5326) Add data structure descriptor
Date Thu, 18 Aug 2016 09:06:22 GMT
David Leangen created FELIX-5326:

             Summary: 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

View raw message