>From a high level: This processor allows setting the address to be read dynamically from the incoming connection. It has to produce a schema for every trigger ( by mapping PLC4X types to NIFI record types). Since the types will then be dynamic, there should be a schema cache such that we reduce the likelihood of recalculating the schema each trigger -OR- we could just not make the address dynamic and add the caching later ( in other words restrict the use to how the processor actually works best currently).
So, maybe if we can agree to remove the dynamic addressing, we can just take this until we can improve it with the caching? On Wed, May 11, 2022 at 9:21 AM Christofer Dutz <[email protected]> wrote: > Hi Inigo, > > of course do we still think this is a great new feature and I'd be > delighted to have it in develop and perhaps even the next release. > > I also think it's a good idea to merge it back asap, as I think if it's > better than the current version, it's worth having it ... it doesn't have > to be completely finished. > > Chris > > > -----Original Message----- > From: Iñigo Angulo <[email protected]> > Sent: Mittwoch, 11. Mai 2022 11:54 > To: dev <[email protected]> > Subject: Nifi record oriented update > > Hi PLC4X Community, > > I am writing to you regarding the 'Feature/nifi-record' PR. It's been a > while since the last updates here, and we noticed the PR was set to draft > due to inactivity. > There were some discussions ongoing about few topics that could be > enhanced on the code, mainly three things: > - cache for schema, > - expand connection and datatype tests > - review Plc4xCommon and datatype inferece/conversion from PLCReadResponse > > Although these things could indeed be enhanced, the processor was working > fine, so we think these could be improved in the future, by us and anyone > interested on this from the community :) > > During the last week, we have been doing new tests using OPCUA driver with > the record oriented processor. We noticed that, as PLC4X versions have > continue to go on, this PR code has become pretty much deprecated, and some > issues appeared due to version changes and code refactoring... We managed > to solve it locally, but we think it is worth to re-do the contributions on > a new PR, just to asure we keep things updated to the last version... > > So, before doing any change, we wanted to ask if you think this could be a > good idea, and if you still find interesting this Nifi Record Feature. If > you agree, we could work on a new PR and prepare the code to match the new > PLC4X versions, and leave the record oriented processor code at the same > (functional) point it is at the moment. However, we would like to know your > opinion, so we can agree on the expected result. Having a common starting > point and a clear outcome will avoid further technical discussions on > additional functionalities after our work has been done. > > Let us know what you think, > > regards > iñigo > >
