Skip to content

Conversation

@hailtondecastro
Copy link
Contributor

@hailtondecastro hailtondecastro commented Dec 22, 2015

Test case and fix for NH-3079 (#1117) on branch master

@hailtondecastro
Copy link
Contributor Author

containingTypeName: IFutureEnumerable
- conversion: Ignore
name: ComputeFlattenedParameters
containingTypeName: SqlQueryImpl
Copy link
Member

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 })
Copy link
Member

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.
Copy link
Member

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;
Copy link
Member

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() ??
Copy link
Member

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.

Copy link
Contributor

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

@fredericDelaporte
Copy link
Member

I have rebased and refactored this.

@fredericDelaporte fredericDelaporte changed the title Test case and fix for NH-3079 on branch master Fix custom sql loader with composite id Dec 20, 2018
@fredericDelaporte fredericDelaporte added this to the 5.3 milestone Dec 20, 2018
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.
Copy link
Member

@fredericDelaporte fredericDelaporte left a 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.

Copy link
Contributor

@maca88 maca88 left a 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.

@bahusoid
Copy link
Member

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.

@fredericDelaporte
Copy link
Member

Sorry if I have missed getting your own changes before resolving the conflicts this PR had.

Copy link
Member

@bahusoid bahusoid left a 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.

@fredericDelaporte fredericDelaporte merged commit b81e422 into nhibernate:master Mar 31, 2020
georgi-yakimov pushed a commit to georgi-yakimov/nhibernate-core that referenced this pull request Apr 16, 2020
Co-authored-by: Frédéric Delaporte <12201973+fredericdelaporte@users.noreply.github.com>
Co-authored-by: maca88 <bostjan.markezic@siol.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants