Call get_python_classes while there are codes failing #517
Conversation
asyncua/common/structures.py
Outdated
| # the information model(s) it will fail because it makes use of an yet undefined Python class. | ||
| # So for solving this without changing deeply the current implementation of 'get_python_classes' | ||
| # we get get how many DataTypes failed to be converted to Python classes and repeat until the failed | ||
| # conversions is zero or not lower than the previous iteration. |
There was a problem hiding this comment.
OK. that might make things more robust.
but can you move code under the while'in a method so the code is easier to read . So we clearly split between your retry mechanism and the structure code
There was a problem hiding this comment.
I can do so, but for that the section # register classes will also need to move to that function. I don't know if that is desired.
There was a problem hiding this comment.
I am having a look, but seems difficult to decouple the retry from the registration of structures because when there are "failed codes", before the retry it is necessary to register the successfully executed structures.
I am going to push an attempt, but again retry from the registration of structures are inside the coupled. :(
| The node to be processed | ||
| generator: StructGenerator | ||
| Struct generator from the xml description of the node | ||
| Return dict of the registered structures |
There was a problem hiding this comment.
The doc string is rather wrong now. We are are reading the value (an xml string) of a node. byt default "0:OPC Binary"
|
please stop adding all these merge commit. It is much cleaner to rebase your changes on top of master |
jcbastosportela
force-pushed
the
fix_load_data_type_definitions_order_of_data_types_issue
branch
from
5804605
to
fa4c80b
Compare
|
Is there any ambition to get this PR merged? As far as I can see the current master still have the same issue while loading data type definitions. If there are plans to get this fix merged I will pull from master once again. |
…e to dependency order
jcbastosportela
force-pushed
the
fix_load_data_type_definitions_order_of_data_types_issue
branch
from
21ffe04
to
1026846
Compare
|
Also generally, this send to be a quote ugly hack. Exceptions should only be raised and catched in case of errors. Here you are using exceptions to avoid sorting the XML objects |
Well, I agree with you. But I feel that sorting the DataType nodes so all dependencies are resolved may be a much bigger change. It is necessary to consider that a Custom Structured DataType may have members that are other DataTypes defined on that namespace; so this would always require to make some parsing to the XML objects of the DataTypes looking to its members types and determining dependencies and check if all of them are already met, and based on that calculate its position on a list. Obviously it is a solvable problem, I can try to approach the problem in that way. @oroulet do you suggest to reject this approach (even as an intermediary fix) and wait for a solution where the XML objects are sorted? |
|
We can leave that PR open, but I would rather not merge that. It make understanding code even more complicated. |
|
also this is fixingan older version of protocl, newer versions do not use these xml nodes, they use the DataTypeDefiniont attributes |
I use UAModeler to create the models I use. I think it really is a matter of alphabetic order. When I look on the generated .xml file from UAModeler the DataTypes are somewhat sorted alphabetically.
Yeah, fair enough. I think the |
Call get_python_classes while there are codes failing (most likely due to dependency order)