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