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] [Commented] (FELIX-5326) Add data structure descriptor
Date Fri, 19 Aug 2016 06:32:21 GMT

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

David Leangen commented on FELIX-5326:


What is still missing would be:


This would return some kind of descriptor object (maybe a `java.lang.reflect` object, maybe
something else). This descriptor would allow the client to retrieve annotations and other
useful information about that node. The annotations should probably be out of scope, but at
least this will enable easy access.

The only other missing thing would be the tree structure. Since we already parse it, would
be useful to share the structure (children(), parent(), siblings() etc.)

As you say, and I agree, the DTO does indeed represent the schema. Would therefore be very
cool to be able to print [something like this|http://json-schema.org/].

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