-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
model.save() not working ? #446
Comments
Hi, and welcome to the community! The issue isn't with Due to the bug, this call creates a new function directly below the SA layer object, which makes no sense, so Capella probably just ignores it. You can instead create the function below the root package (or any other function or function package), for example with: model.sa.function_package.functions.create(name="Function2")
model.save() After this, Capella should also show this new function in the project explorer. |
Ah, damn it, this is a mess. There's multiple issues at play here, it seems Here's an example that should actually work:
(i.e. use the I'll look into this in more detail (hopefully) later today. |
Now I unfortunately have : AttributeError: 'NoneType' object has no attribute 'functions'... I think it has something to do with create() as you said. Thanks for looking into this ! |
By inheriting from DirectProxyAccessor, DeepProxyAccessor also unintentionally inherited the behaviors that allowed creating objects. This recently led to confusion as to what's possible and what isn't. Part of the fix to #446.
Previously when retrieving objects using a RoleTagAccessor that has a non-empty `classes` argument, objects that didn't match the specified classes were simply filtered out and ignored. This caused two problems: 1. It made it more difficult to spot potential metamodel mismatches with upstream Capella. 2. The implementation (using `ElementList.filter`) decoupled the list from the model and therefore prevented modifying the model through it. This commit changes the implementation to strictly verify that the actual classes match those expected by the metamodel, and will raise an exception in case of any mismatch. Part of the fix to #446.
By inheriting from DirectProxyAccessor, DeepProxyAccessor also unintentionally inherited the behaviors that allowed creating objects. This recently led to confusion as to what's possible and what isn't. Part of the fix to #446.
Previously when retrieving objects using a RoleTagAccessor that has a non-empty `classes` argument, objects that didn't match the specified classes were simply filtered out and ignored. This caused two problems: 1. It made it more difficult to spot potential metamodel mismatches with upstream Capella. 2. The implementation (using `ElementList.filter`) decoupled the list from the model and therefore prevented modifying the model through it. This commit changes the implementation to strictly verify that the actual classes match those expected by the metamodel, and will raise an exception in case of any mismatch. Part of the fix to #446.
The "list is not coupled" issue with |
Hello,
I'm very new to this community (and to coding in general) and I just started using capellambse but I already got an issue with model.save(), who seems not to be working (even after reloading my model and everything).
The modifications seem to be saved in the notebook but not on the capella model.
What should I do to make it work ?
Thanks a lot !
The text was updated successfully, but these errors were encountered: