Skip to content
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

Open
redd-gs opened this issue Aug 7, 2024 · 6 comments
Open

model.save() not working ? #446

redd-gs opened this issue Aug 7, 2024 · 6 comments

Comments

@redd-gs
Copy link

redd-gs commented Aug 7, 2024

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.
image

What should I do to make it work ?

Thanks a lot !

@Wuestengecko
Copy link
Member

Hi, and welcome to the community!

The issue isn't with save(), but with the fact that this create() call doesn't throw an error. sa.all_functions is an aggregate list of all functions that exist on that layer. It shouldn't allow you to create new functions directly there, because it's not clear where exactly in the model this function should then be placed (i.e. under which parent function or package).

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.

@redd-gs
Copy link
Author

redd-gs commented Aug 7, 2024

Thanks a lot for this quick answer and for your welcoming !
Now I have another problem :
image

I think it expects a parent element but doesn't find one. I've tried to check other solutions but can't seem to find one... Do you know how to proceed to make it work ? Thanks again

@Wuestengecko
Copy link
Member

Ah, damn it, this is a mess. There's multiple issues at play here, it seems create() is broken in more than one way.

Here's an example that should actually work:

model.sa.root_function.functions.create(name="Function2")

(i.e. use the root_function instead of the function_package)

I'll look into this in more detail (hopefully) later today.

@redd-gs
Copy link
Author

redd-gs commented Aug 7, 2024

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 !

Wuestengecko added a commit that referenced this issue Aug 12, 2024
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.
Wuestengecko added a commit that referenced this issue Aug 12, 2024
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.
Wuestengecko added a commit that referenced this issue Aug 12, 2024
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.
Wuestengecko added a commit that referenced this issue Aug 12, 2024
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.
@Wuestengecko
Copy link
Member

The "list is not coupled" issue with function_package.functions should be fixed now. However I'm not sure where you got "AttributeError: 'NoneType' object has no attribute 'functions'" - could you please test that again (it might already be fixed now as well), and if not, post the code that you ran?

@redd-gs
Copy link
Author

redd-gs commented Aug 26, 2024

Hi ! Sorry for the late response. I actually tried again with the same code and I still have the same problem as before, which is the "List is not coupled issue".
I've tried many things to make it right but it still seems that the same problem is remaining....
As for the other code, I was simply trying the root_function method but it doesn't seem to work either :
image

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

No branches or pull requests

2 participants