HHH-16957 Embeddable cannot have only one @generated field #8543
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| scope.inTransaction( | ||
| session -> { | ||
| TestEntity testEntity = new TestEntity( 1l, "prop1", "prop2" ); | ||
| session.save( testEntity ); |
Check notice
Code scanning / CodeQL
Deprecated method or constructor invocation
| if ( subtype instanceof BasicType ) { | ||
| final boolean insertable; | ||
| final boolean updateable; | ||
| if ( generatedWithNoParameter( onExecutionGenerator ) ) { |
There was a problem hiding this comment.
Please help me understand, why would we want to set insertable/updatable of a property to false when it has a generator. Doesn't this depend on the generation types? Or should we "care" about the config at all i.e. rely on the use configuring this correctly? Also, how does this interact with the writable flag of @org.hibernate.annotations.Generated?
| final boolean insertable; | ||
| final boolean updateable; | ||
|
|
||
| if ( generatedWithNoParameter( onExecutionGenerator ) ) { |
There was a problem hiding this comment.
Same question as above about insertability/updatability.
| dirtinessChecker != null ? | ||
| dirtinessChecker.isDirty( attributeIndex, attributeMapping ).isDirty() : |
There was a problem hiding this comment.
I'm a bit concerned that dirtiness checking is so high level i.e. just for root attributes. Shouldn't this be part of the AttributeAnalysis? Also, can that maybe check nested dirtiness automatically when using dynamic updates? I think that would make the whole process a bit simpler as we could pass along the AttributeAnalysis info into the decomposition.
There was a problem hiding this comment.
My idea is that while building UpdateValuesAnalysisImpl and the respective AttributeAnalysis, we could compute e.g. a bit set that says if a selectable index is to be included or not. That way, we could have a very simple check in the decompose step and push the logic with generators into the analysis phase where it IMO belongs. We can even pre-compute some model based info to only do checks at runtime that really rely on the value/dirtiness.
| jdbcValueBindings, | ||
| tableMapping, | ||
| (valueIndex, bindings, table, jdbcValue, jdbcMapping) -> { | ||
| if ( jdbcMapping instanceof EmbeddedAttributeMapping ) { |
There was a problem hiding this comment.
Since EmbeddedAttributeMapping does not extend SelectableMapping, this branch does not make much sense, unless I am missing something.
|
closed in favour of #9280 |
2 participants
https://hibernate.atlassian.net/browse/HHH-16957