PyI40AAS issueshttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues2021-01-25T16:24:07+01:00https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/130Add property.setter for attributes of type NamespaceSet2021-01-25T16:24:07+01:00Igor GarmaevAdd property.setter for attributes of type NamespaceSetAll classes that inherit from class Namespace should have property.setter for each NamespaceSet attribute, so that each NamespaceSet attribute can be set with iterable object.
Example:
```
shell = AssetAdministrationShell(asset, identif...All classes that inherit from class Namespace should have property.setter for each NamespaceSet attribute, so that each NamespaceSet attribute can be set with iterable object.
Example:
```
shell = AssetAdministrationShell(asset, identification)
...
shell.view = [view1, view2, view3]
...
shell.view = (view1, view2)
```https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/124model: Fix docstring of AASReference.__init__ w.r.t. to target_type parameter2021-10-28T21:12:49+02:00Igor Garmaevmodel: Fix docstring of AASReference.__init__ w.r.t. to target_type parameterDelete `target_type` parameter in `__init__` of `AASReference`. Use for `type` type of last element of `key`.
If it is not possible, please fix doc of `__init__`: replace "type_" with "target_type"Delete `target_type` parameter in `__init__` of `AASReference`. Use for `type` type of last element of `key`.
If it is not possible, please fix doc of `__init__`: replace "type_" with "target_type"https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/115These docstrings may need a rework2021-02-25T11:11:48+01:00Sebastian Heppners.heppner@iat.rwth-aachen.deThese docstrings may need a reworkThis is a collection of docstrings that may need some reformulating. I am happy to provide it, though would like to discuss the content beforhand.
* [x] `model.__init__`: Update docstring
* [x] `aas` module docstring and `aas.Asset` sho...This is a collection of docstrings that may need some reformulating. I am happy to provide it, though would like to discuss the content beforhand.
* [x] `model.__init__`: Update docstring
* [x] `aas` module docstring and `aas.Asset` should have a note about how `Assets` are handled now
* [x] `aas.View`: Resolve "Todo: What does this do exactly?" and with resolving, update docstring to be clear about what it does.
* [x] `base.Qualifiable`: Unclear formulation
* [x] `base.HasExtension`: Unclear explanation of attribute `namespace_element_sets`
* [x] `base.Referable.parent`: Confusing by mentioning a `Reference`, even though it is actually a `Namespace`
* [x] `base.Reference.key`: Unclear formulation
* [x] `base.UnexpectedTypeError`: `base.Reference` does not have a method `resolve()`
* [x] `base.ValueReferencePair`: Unclear formulation, does not have any reference to any other part of the meta-model
* [x] `provider.AbstractObjectProvider.get_identifiable`:
* Docstring says "find identifiable by id_short", parameter is of type `base.Identifier` though.
* Missing docstring for ":param: identifier"
* ":raises: KeyError: Mentioning `Referable` here, while correct, may be confusing to some. Maybe use `Identifiable` here?
* [x] `provider.AbstractObjectStore.update`: Missing docstring
* [x] `submodel.OperationVariable`: is in fact, not a `SubmodelElement`
* [x] `submodel.RelationshipElement`: The mentioned subject-object relation is unclear to me. Disregard this, if this a concept I simply don't know
* [x] `Referable.display_name` description is unclear
* [x] `base.Formula`: If we don't support it anymore (in V30RC1, because formulas are not unambiguously identifiable), mention this somewhere where it makes sense
* [x] `aas.adapter.__init__`: Update docstring
* [x] `adapter.json.json_deserialization`: Second paragraph of module docstring seems outdated
* [x] `model.base.LangStringSet`: Has no Entry in the documentation (Due to it being Dict[str, str]) and no class
* [x] `model.base.ValueList`: Has not Entry in the documentation
* [x] `backend.__init__`: Missing module docstring
* [x] `backend.couchdb`: Missing module docstringSebastian Heppners.heppner@iat.rwth-aachen.deSebastian Heppners.heppner@iat.rwth-aachen.dehttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/88Inability to test for parameter `relative_path` in calls of `backends.Backend...2020-10-28T17:08:35+01:00Sebastian Heppners.heppner@iat.rwth-aachen.deInability to test for parameter `relative_path` in calls of `backends.Backend.update_object()` and `backends.Backend.commit_object()` from `model.base.Referable` using `unittest.mock.Mock`Especially during execution of the `model.base.Referable.commit()` function, the `relative_path` variable is built iteratively by traversing the Referable-tree. Whenever there is a nonempty source, the `backends.Backend.commit_object()` ...Especially during execution of the `model.base.Referable.commit()` function, the `relative_path` variable is built iteratively by traversing the Referable-tree. Whenever there is a nonempty source, the `backends.Backend.commit_object()` function is called with the current `relative_path`. Therefore, the `relative_path` variable is likely to change after a call. This is impractical, because `unittest.mock.call` seems to only log a reference to the variables that were used in that call, rather than saving a duplicate of the current state of those variables during function call.
Here is a minimal example that shows this behavior:
```
from unittest import mock
test_mock = mock.Mock()
test_parameter = ["only_entry_of_this_list"]
test_mock(argument=test_parameter)
test_parameter.append("another_entry_of_this_list")
test_mock.assert_has_calls([mock.call(argument=["only_entry_of_this_list"])])
```
leads to:
```
AssertionError: Calls not found.
Expected: [call(argument=['only_entry_of_this_list'])]
Actual: [call(argument=['only_entry_of_this_list', 'another_entry_of_this_list'])]
```
Therefore, it is impossible to check, if the `relative_path` has been correct during the time of the function call, using the `unittest.mock.Mock`-object.
While I have reviewed with the debugger, that the function gets called with the correct `relative_path` at each time, I don't see a way to "prove it" using unittests, without altering the actual code to allow for testing, which in my opinion shouldn't really be done.Sebastian Heppners.heppner@iat.rwth-aachen.deSebastian Heppners.heppner@iat.rwth-aachen.de