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

Alessandro Rossignoli commented on PLC4X-113:
---------------------------------------------

Thank you [~julian.feinauer], looking here: 
[https://github.com/apache/plc4x/blob/4a74ff526aeb57e978005e37c878fe55021462aa/plc4j/spi/src/main/java/org/apache/plc4x/java/spi/messages/DefaultPlcWriteRequest.java#L255]

I get back a null on plcFieldPlcValueBiFunction, so there are not handlers 
available.

To be completely honest I am using plc4j in Scala and using an Avro 
GenericData.Array instead of a plain array or a java.util.ArrayList, I will try 
those basic types first to get into a more basic and known situation.

> 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
(v8.3.4#803005)

Reply via email to