client persisting load_data_type_definitions() for future use

[dpmilian]

Following this example, from a client I need to be able to use custom data structures defined in the remote server. Loading these definitions is a slow process (approx. 10 seconds for a relatively small amount of custom types) so I was looking at a way of making this process faster.

Ideally the first time connecting to a known server I could save the custom data structures to a local file, and the next connections could directly load the local file without having to request the information from the server. I've attempted to persist the dictionary of objects returned by load_data_type_definitions() to a local binary file using the pickle or dill module, but since the python classes for the custom structs are loaded on the fly, it doesn't play well with the serialization.

Is there an easier way to do this? I had a look at the xmlexporter/ xmlimporter modules, but if I'm not mistaken they are geared towards setting up the objects on a server instance (either directly or through a client connected to it).

[AndreasHeine]

this is more difficult then it sounds... from spec. a opc ua server can change its model while runtime!
if a client connects he need to reload the definitions in order to function properly -> if a server emits a ModelChangeEvent (Subtypes of GeneralModelChangeEventType or BaseModelChangeEventType) you need to figure out what has changed and maybe reload the definitions. if you create a local copy you need to validate that the definitions are sync with the current state of the server, which in result is a reload aswell.

[dpmilian]

I understand this, but the usual scenario (for me at least!) is that you have a model on the server that you have to program your logic against. This model remains static for that application. If that model (including types) changes, probably you have to change your business logic too.

It seems like there is a lot of effort put into getting an appropriate python dataclass model from the server and not being able to use it because you can't store the types and later use them to design the application levels of your program against. In other words, have the option to have a "discovery" phase where you pull in the classes that represent your server's model, and then an "operations" phase where you use that knowledge to do something with that structure. If it changes (the events you have mentioned) then you have to restart the process and evaluate the changes.

[schroeder-]

We could expaned the load_data_type_definitions or a extended function to return all source code generated for exec. You could save that code and we could make a function like restore_data_type_definitions, that runs that code again.

[dpmilian]

that sounds great, I've been writing my own version of this but was a bit stuck with the required parameters for the register_extension_object(...), register_enum(...) and register_basetype(...) functions of the ua_types module. When I get some time I'll send some code and we can discuss it

[oroulet]

In fact, exporting as code was a feature earlier, but removed during some refactoring

[dpmilian]

could you point me to where this happened or if there is a reason behind the decision to remove this feature (other than cleanup)?

[oroulet]

nobody seems to use that feature and as written over it could have bad side effect.

[schroeder-]

It isn't removed, it is only implemted for the old structured types (TypeDictonaries/pre 1.04) see

opcua-asyncio/asyncua/common/structures.py

Line 193 in a6fe064

def save_to_file(self, path, register=False):

[oroulet]

ok then we have the status. I clearly remember considering nobody used that feature