-
Notifications
You must be signed in to change notification settings - Fork 931
Fix custom sql loader with composite id #452
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
Conversation
01c2af8 to
9cbb19b
Compare
| containingTypeName: IFutureEnumerable | ||
| - conversion: Ignore | ||
| name: ComputeFlattenedParameters | ||
| containingTypeName: SqlQueryImpl |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not ignoring it would cause an interface change by adding an async counterpart to a method belonging to an interface.
Moreover it generates an async counterpart due to a second level cache check, which would incurs IO only if a distributed cache is enabled.
There is also an IType.GetPropertyValue call which has an async counterpart, but it is called only on component types which currently have a fully synchronous implementation for it.
| session | ||
| .GetNamedQuery("personNoComponentSql") | ||
| .SetParameter(0, new PersonNoComponent { IdA = 17, IdB = 18 }) | ||
| .SetParameter(1, new PersonNoComponent { IdA = 19, IdB = 20 }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The tests implying custom sql loaders only have one parameter. This test allows to check the change works also when multiple parameters needs flattening.
| /// if true, the first ? will not be verified since | ||
| /// its needed for e.g. callable statements returning a out parameter | ||
| /// If true, the first positional parameter will not be verified since | ||
| /// its needed for e.g. callable statements returning an out parameter. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Current code base always calls this method with false. The true path looks like dead code. And maybe it was always dead, if that can be useful only for callable statement, as I do not think callable statements have been ported.
| // Values and Types may be overriden to yield refined parameters, check them | ||
| // instead of the fields. | ||
| var values = Values; | ||
| var types = Types; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Trying to use here ValueArray() and TypeArrays() instead wrecks CollectionFilterImpl and ExpressionFilterImp, because they override these methods and cause them to yield values failing the validation. So I had to use the Values and Types properties instead.
|
|
||
| public override object[] ValueArray() | ||
| { | ||
| return _flattenedValues?.ToArray() ?? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could also be Values.Cast<object>().ToArray(). In which case it could be moved in the base class instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a TODO for 6.0 for changing Values type to IList<object>.
|
I have rebased and refactored this. |
9cbb19b to
d2c8863
Compare
fc7730b to
d99c968
Compare
5be374a to
72996be
Compare
Disable it for the parameters flattening method, to avoid a binary breaking change: it would add an async counterpart to an interface method. Moreover it generates an async counterpart due to a second level cache check, which would incurs IO only if a distributed cache is enabled. There is also an `IType.GetPropertyValue` call which has an async counterpart, but it is called only on component types which currently have a fully synchronous implementation for it.
72996be to
979aa4d
Compare
fredericDelaporte
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I consider this PR good for merging.
But as I have refactored it heavily, I also consider it should be approved by someone else.
maca88
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Simplified FlattenTypesAndValues to use a for statement and a single list for types/values.
Hm.. I believe I've been pushing something very similar some time ago. It seems those changes were lost by force push.. Let me check tomorrow If I also refactored something else. |
|
Sorry if I have missed getting your own changes before resolving the conflicts this PR had. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeap. Pretty much the only change I've made. My changes are here just for reference.
Co-authored-by: Frédéric Delaporte <12201973+fredericdelaporte@users.noreply.github.com> Co-authored-by: maca88 <bostjan.markezic@siol.net>
Test case and fix for NH-3079 (#1117) on branch master