[jira] [Updated] (PLC4X-113) Implement support for complex field types in the PLC4X API

["Julian Feinauer (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/PLC4X-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julian Feinauer updated PLC4X-113:
----------------------------------
    Description: 
*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}


  was:
*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}



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