felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Bosschaert (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-5326) Add data structure descriptor
Date Thu, 18 Aug 2016 15:38:20 GMT

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

David Bosschaert commented on FELIX-5326:
-----------------------------------------

The JSON Codec now supports encoding/decoding 'deep' DTO structures. For example the following
DTO 
{code}        MyDTO dto = new MyDTO();
        dto.count = Count.ONE;
        dto.ping = "'";
        dto.pong = Long.MIN_VALUE;

        MyEmbeddedDTO embedded = new MyEmbeddedDTO();
        embedded.alpha = Alpha.B;
        embedded.marco = "jo !";
        embedded.polo = 327;
        dto.embedded = embedded;{code}

produces the following JSON:
{code:javascript}{"ping":"'","count":"ONE","pong":-9223372036854775808,"embedded":{"polo":327,"alpha":"B","marco":"jo
!"}}{code}
(See test case here: https://svn.apache.org/viewvc/felix/trunk/converter/src/test/java/org/apache/felix/converter/impl/json/JsonCodecTest.java?r1=1756806&r2=1756805&pathrev=1756806
)

While this isn't yet an implementation of the tree/visitor API it does handle the serialization
part. In this case the DTO is the schema for the JSON and it can be converted in both directions.

On the visitor - this can already be done by an adapter I think. An adapter can be used to
change the behaviour of the standard converter in some way. For example if you want certain
types of conversions to be different. An adapter could also be used to do something else if
your visitor wants that. It might be useful to experiment with the adapters to see how far
this will work for the visitor idea.

On the tree API. If you convert a DTO to a map then you get something that might be similar.
If you do
{code:java}Map m = converter.convert(dto).to(Map.class);{code}
then you can do 
{code:java}m.get("embedded").set("polo", 42);{code}
No path-like notation yet, but maybe useful somehow?

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

Mime
View raw message