Hi Julia,

+1 for a JPA style on top addition on plc4x .

In addition to the comments from Chris:
We had a discussion on this topic a while ago here 
https://lists.apache.org/thread.html/dfca30f6c3319e592c4a6412924edc9a31f2e18844204dc373eebc5d@%3Cdev.plc4x.apache.org%3E
 
<https://lists.apache.org/thread.html/dfca30f6c3319e592c4a6412924edc9a31f2e18844204dc373eebc5d@%3Cdev.plc4x.apache.org%3E>

Sebastian

PS: FYI: here is a good search point (mailinglist web search) in case you 
didn’t knew: https://lists.apache.org/list.html?dev@plc4x.apache.org:lte=1y:jpa 
<https://lists.apache.org/list.html?dev@plc4x.apache.org:lte=1y:jpa> :)

> Am 31.07.2018 um 12:42 schrieb Julian Feinauer <j.feina...@pragmaticminds.de>:
> 
> Hey Chris,
> 
> 
> 
> I get your point regarding reading "basic" types and I agree.
> 
> And the idea with the mapping I had was indeed meant not directly on the plc 
> level but as you outlined one level above where plc4j takes care of 
> generating a suitable set of requests and assembles the struct for the result.
> 
> The description for the result structure should be given with plc4j addresses 
> and then everything would stay the same for the requests.
> 
> 
> 
> Should I create a Ticket for this or do you want to?
> 
> Then we can conserve our discussion there until someone really plans to 
> implement this.
> 
> 
> 
> Best Julian
> 
> 
> 
> 
> 
> Am 30.07.18, 13:46 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
> 
> 
> 
>    Hi Julian,
> 
> 
> 
> 
> 
> 
> 
>    Well the reason for this was to allow explicit generic handling of the 
> responses. 
> 
> 
> 
>    There had been quite a lot of refactoring regarding this in the early 
> times of PLC4X. 
> 
> 
> 
> 
> 
> 
> 
>    I do agree that it limits the extensibility but I remember in the 
> beginning we even had hard coded types so there were IntegerReadRequests and 
> LongWriteRequests.
> 
> 
> 
>    The idea behind this was to be able to have explicit control over the set 
> of types used. We loosened things a little by using generics. 
> 
> 
> 
> 
> 
> 
> 
>    The main idea behind this is, that in Java we use different datatypes as 
> in the different types of PLCs. Therefore we are expecting each driver to be 
> able to map certain Java types to the ones used in that particular protocol. 
> It makes things a lot more complicated when allowing complex types, because 
> every driver then has to know how to deal with this. In the end I was afraid 
> to have PLC4X support some features on one driver and others on another. 
> After all I haven't come across a single protocol, that natively supports 
> Lists for example. Usually Arrays is the only thing supported. I know that 
> OPC-UA seems to support datastructures as well as Beckhoff ADS (I think). So 
> how could you change your code from Beckhoff to Siemens for example?
> 
> 
> 
> 
> 
> 
> 
>    Even if no work has been done on this yet, I was always thinking of having 
> some sort of mechanism on top of PLC4X that supports Datastructures and acts 
> similar to how JPA does on top of JDBC. These mechanisms - which could be 
> part of the PLC4X project - could for example map POJOs into Request with 
> multiple items and handle the marshalling and unmarshalling transparently. 
> Eventually PLC4X could also allow skipping the marshalling and unmarshalling, 
> if the corresponding protocol supports complex datatypes.
> 
> 
> 
> 
> 
> 
> 
>    What do you think?
> 
> 
> 
> 
> 
> 
> 
>    Chris
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>    Am 29.07.18, 13:37 schrieb "Julian Feinauer" 
> <j.feina...@pragmaticminds.de>:
> 
> 
> 
> 
> 
> 
> 
>        Hi all,
> 
> 
> 
> 
> 
> 
> 
>        After going through the code I have one question about the 
> “Typesystem”.
> 
> 
> 
>        From what I see, currently the java class(-name) is used as type 
> parameter.
> 
> 
> 
>        Is there a specific reason for this?
> 
> 
> 
>        I am asking because this limits, in my eyes, the extensibility of the 
> typesystem massively, e.g., for defining nullability or later on extending 
> the typesystem to lists, arrays, maps or structs.
> 
> 
> 
>        A concrete use case would be to map a struct, e.g., in a S7 program 
> directly to a struct with a shema definition given, e.g., in avro or json.
> 
> 
> 
>        I think this could be a pretty cool use case later on, especially when 
> communication with PLCs becomes more common and TIA programmers start to 
> incorporates special structs for communication.
> 
> 
> 
> 
> 
> 
> 
>        My suggestion would be to use a typesystem, e.g., similar to the one 
> used in Apache Calcite 
> (https://calcite.apache.org/apidocs/org/apache/calcite/rel/type/RelDataType.html
>  ) and to add a static util class to convert between Java Classes and 
> internal types to keep the public API’s “as is”.
> 
> 
> 
> 
> 
> 
> 
>        What do you think of this suggestion or what drawbacks do you see?
> 
> 
> 
> 
> 
> 
> 
>        Best
> 
> 
> 
>        Julian
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

Reply via email to