-
Notifications
You must be signed in to change notification settings - Fork 8
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
Comments
After this is fixed we can switch back to the optimized query |
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! |
I think you can see the id in the url of the descriptor gui else you have to check in the db table. |
The property descriptor id is not at all visible in the GUI - you have to get it from the database:
|
finally tracked it down to: liima/AMW_business/src/main/java/ch/puzzle/itc/mobiliar/business/property/entity/PropertyEntity.java Line 196 in 24c7b02
now investigating if |
If the descriptor is part of the copied resource it should never reference the same descriptor. |
Ok - this means the simple solution above does not work - it would always create a new descriptor. |
Most likely this is the underlying cause for #484.
How to reproduce:
myUniqueValue123
in the new instance propertyselect * from tamw_property where to_char(substr(value, 0, 30)) = 'myUniqueValue123';
The descriptor_id should be the same as above.
=> 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....
The text was updated successfully, but these errors were encountered: