[
https://issues.apache.org/jira/browse/PLC4X-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16820855#comment-16820855
]
Julian Feinauer commented on PLC4X-113:
---------------------------------------
Hi [~Mathi_LTAZ], I agree with you and your point is absolutely fair.
We have to cleary distinguish between our Node tree or container format AND
Metadata about describing the Types and furhter Metadata (like the OPC UA Node
Tree).
These are related but different fields.
But, e.g. with parsing a TIA file or reading symbolic adresses, one would also
be able to support "Strucutre" queries against a PLC like "give me all
primitives in DB..." or so. This then brings us really close to the DB world
where we have metadata and values, so I like to see it that way. The DB Row is
similar to the (Complex) Data types and the metadata is similar to the shard /
schema / table / column spec you have in a DB.
> Implement support for complex field types in the PLC4X API
> ----------------------------------------------------------
>
> Key: PLC4X-113
> URL: https://issues.apache.org/jira/browse/PLC4X-113
> Project: Apache PLC4X
> Issue Type: New Feature
> Components: API
> Reporter: Julian Feinauer
> Priority: Critical
>
> *This is a (possibly) incompatible change.*
> Currently we have support for primitives as well as lists (arrays) as first
> class "ciitzens" of the PLC4X model.
> Especially, when thinking about OPC UA, but also other protocols like ADS
> (and even S7) support complex objects in their programming model.
> Thus, it is necessary to refactor / extend the API to support these complex
> objects.
> I guess we need at least
> * primitives
> * lists
> * maps (should be equal to "structs")
> Basically, this should be roughly equivalent to what one can represent with
> JSON.
> Thus, the API could be structured i two ways.. first, we could use an
> internal Node Tree to represent the objects, but we could also provide to use
> someone elses NodeTree or structure to represent the Objects.
> For example Jackson.. this would even allow us to directly map these objects
> to POJOs via Jackson.
> As example for such a model, one can look at that of Apache Calcite:
> https://github.com/apache/calcite/blob/3fa29455664bec0056c436491b369e0cd72242ea/core/src/main/java/org/apache/calcite/rel/type/RelDataType.java
> They have an interface with methods
> {code:java}
> public interface DataType
> {
> // Checker
> boolean isMap();
> boolean isList();
> boolean isPrimitive();
> // Getter for complex types
> DataType get(String key);
> DataType get(Long i);
>
> // Primitive getters
> long getLong();
> String getString();
> //...
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
