Skip to content

Conversation

@zrgt
Copy link
Contributor

@zrgt zrgt commented Nov 20, 2024

Previously, we used vars() to iterate over all attributes of an object when updating it from another object (Referable.update_from()).

However, vars() only retrieves the instance's __dict__, e.g. the object's attributes, but does not include properties. As a result, when you use vars(other), you get the _id_short attribute instead of the id_short property.

This made it impossible to utilize custom setter methods we developed for certain cases, e.g. when properties should be immutable.

This now adapts the Referable.update_from() method to utilize dir() instead, which iterates over all attributes and properties of the object. We skip callables and private attributes. We use setattr() to set attributes and properties, so that the correct setter methods will be used.

Furthermore, we now raise an error if an immutable property changed between the two versions of the object.

Fixes #215

vars() only retrieves the instance's
__dict__—that is, the object's
 attributes—but does not include
  properties.
As a result, when you use vars(other),
 you get the _id_short attribute instead
  of the id_short property.

  dir() iterates over all attributes and
   properties of the object.
   We skip callables and private attrs.
   We use setattr() to set attributes and
    properties, so setter funcs will be
    used.
@zrgt
Copy link
Contributor Author

zrgt commented Nov 20, 2024

The question here is: how should we handle properties that are not permitted to be set, such as SubmodelElementList.order_relevant?

In the previous solution, we simply set the attribute, even though it was not allowed. However, with the vars() and setattr() approach, an exception is raised, indicating either that no setter exists for the property or that setting it is explicitly forbidden.

@Frosty2500
Copy link
Contributor

My solution to this problem is:
We keep using dir() and if we encounter a property with no setter we directly set the underlying private attribute. This should fix #215 while keeping the rest of the functionality the same.
But we can gladly discuss this in the next meeting, I am open for other solutions.

@Frosty2500
Copy link
Contributor

@zrgt or @s-heppner it would also be good if one of you changes the branch this PR is merged into to develop from main.

@zrgt zrgt changed the base branch from main to develop April 18, 2025 11:47
@Frosty2500
Copy link
Contributor

Ok then I will add that an error is thrown when an attribute that should not be set has been changed in the newer version of the object.

@s-heppner
Copy link
Contributor

After discussing this in the Dev-Team, we came to the following conclusion:

The update_from() method expects two different versions of the exact same object, where one should be updated from the other. Because of this, we assume all immutable attributes have to have the exact same value (otherwise either the attributes were not immutable, or it is not exactly the same object). If the method encounters a changed immutable attribute it therefore means something went wrong and needs to throw an exception.

This behavior should also be noted in the method docstring.

@Frosty2500
Copy link
Contributor

There seems to be a problem on the side of the eclipse foundation which is why the test is failing.
I can recommit this latter when their problem is fixed so the test passes.

@s-heppner
Copy link
Contributor

Yes, there seems to be an outage of the Eclipse services at the moment.

Copy link
Contributor

@s-heppner s-heppner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@s-heppner s-heppner marked this pull request as ready for review May 20, 2025 12:16
@s-heppner s-heppner merged commit f780c47 into eclipse-basyx:develop May 26, 2025
15 checks passed
@s-heppner s-heppner deleted the fix/update_from branch May 26, 2025 08:40
Frosty2500 added a commit to rwth-iat/basyx-python-sdk that referenced this pull request Jul 10, 2025
…yx#338)

Previously, we used `vars()` to iterate over all attributes of an object
when updating it from another object (`Referable.update_from()`).

However, `vars()` only retrieves the instance's `__dict__`, e.g. the 
object's attributes, but does not include properties. As a result, when 
you use `vars(other)`, you get the `_id_short` attribute instead of the 
`id_short` property.

This made it impossible to utilize custom setter methods we developed
for certain cases, e.g. when properties should be immutable.

This now adapts the `Referable.update_from()` method to utilize `dir()`
instead, which iterates over all attributes and properties of the 
object. We skip callables and private attributes. We use `setattr()` to 
set attributes and properties, so that the correct setter methods will 
be used.

Furthermore, we now raise an error if an immutable property changed 
between the two versions of the object.

Fixes eclipse-basyx#215 

---------

Co-authored-by: Sercan Sahin <[email protected]>
zrgt added a commit to rwth-iat/basyx-python-sdk that referenced this pull request Nov 18, 2025
…yx#338)

Previously, we used `vars()` to iterate over all attributes of an object
when updating it from another object (`Referable.update_from()`).

However, `vars()` only retrieves the instance's `__dict__`, e.g. the 
object's attributes, but does not include properties. As a result, when 
you use `vars(other)`, you get the `_id_short` attribute instead of the 
`id_short` property.

This made it impossible to utilize custom setter methods we developed
for certain cases, e.g. when properties should be immutable.

This now adapts the `Referable.update_from()` method to utilize `dir()`
instead, which iterates over all attributes and properties of the 
object. We skip callables and private attributes. We use `setattr()` to 
set attributes and properties, so that the correct setter methods will 
be used.

Furthermore, we now raise an error if an immutable property changed 
between the two versions of the object.

Fixes eclipse-basyx#215 

---------

Co-authored-by: Sercan Sahin <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Referable.update_from() doesn't update parent namespace

3 participants