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

New release of relation uses old prop descriptor for copied instance property #487

Closed
yvespp opened this issue May 10, 2019 · 8 comments · Fixed by #659
Closed

New release of relation uses old prop descriptor for copied instance property #487

yvespp opened this issue May 10, 2019 · 8 comments · Fixed by #659
Assignees
Labels

Comments

@yvespp
Copy link
Member

yvespp commented May 10, 2019

Most likely this is the underlying cause for #484.

How to reproduce:

  1. Create new resource resA of type application
  2. Create new resource resB of any type
  3. In resB add an instance property. Take note of the descriptor id.
  4. In resA add resB as a consumed relation
  5. In relation form resA to resB set the value to myUniqueValue123 in the new instance property
  6. In the DB search for the new value: select * from tamw_property where to_char(substr(value, 0, 30)) = 'myUniqueValue123';
    The descriptor_id should be the same as above.
  7. Create a new release of resB

=> search the DB again. It should have two values with two different deployment descriptor ids as the copy created a new resource with a new descriptor.
But what happens is that the two values have the same descriptor id, meaning the value is attached to the property descriptor of the old release instead of the new one.
This then causes the optimized oracle query to fetch wrong data which in turn causes an exception. The old query is immune to this.
If you set the a new property value in the relation from resA to resB it then gets attached to correct descriptor.

If I change the descriptor id of the new property to the descriptor id of the new release in the DB, then the optimized query works and also shows the copied value.

This bug seems to have been in Liima for a long time....

@yvespp
Copy link
Member Author

yvespp commented Sep 3, 2019

After this is fixed we can switch back to the optimized query

@sdedijer
Copy link
Contributor

Hi @yvespp ,

Sorry for asking it here as well, but I need your help again. Thanks for nice step-by-step description, but I got stuck already on the step number 3, I don't find descriptor_id once I Add new instance Property. I don't see this descriptor_id in GUI. Could you please help me how to find it?

Thanks a lot in advance!

@yvespp
Copy link
Member Author

yvespp commented Jan 30, 2020

I think you can see the id in the url of the descriptor gui else you have to check in the db table.

@mburri
Copy link
Member

mburri commented Jan 15, 2021

The property descriptor id is not at all visible in the GUI - you have to get it from the database:

select * from TAMW_PROPERTYDESCRIPTOR t where PROPERTYNAME = 'new-property'

@yvespp
Copy link
Member Author

yvespp commented Jan 15, 2021

The id is visible for me in the url under propDescId...:
image

@mburri
Copy link
Member

mburri commented Jan 20, 2021

finally tracked it down to:

now investigating if target.setDescriptor(getDescriptor().getCopy(new PropertyDescriptorEntity(), copyUnit)); fixes the issue...
@yvespp are there cases where a copied property should reference the old property descriptor?

@yvespp
Copy link
Member Author

yvespp commented Jan 20, 2021

If the descriptor is part of the copied resource it should never reference the same descriptor.
If the descriptor is not part of the copied resource (when the descriptor is defined on the type) it should reference the same descriptor as before.

@mburri
Copy link
Member

mburri commented Jan 21, 2021

Ok - this means the simple solution above does not work - it would always create a new descriptor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
3 participants