Aaieee... the SQLite problem looks like a bug in SQLite itself. I've
reported it to their users list and will watch for results. There
seems to be something broken about the named parameter binding in the
subquery limit clause.
Patrick Earl
On Mon, May 30, 2011 at 8:04 PM, Patrick Earl <[email protected]> wrote:
> This is fantastic. Thanks for starting this Fabio. I'm looking at
> the failing SQLite limit test at the moment. Fabio shared some
> thoughts with me about future work in the parameter area and it will
> be good to finish the change at some point. Parameters have been a
> sore spot for a long time and I'm happy there's a reasonable solution
> defined. :)
>
> Patrick Earl
>
> On Mon, May 30, 2011 at 7:57 AM, Fabio Maulo <[email protected]> wrote:
>> Hi team.
>> I done a "minor" refactoring around parameters.
>> To avoid to touch everything, the begin of the refactoring is in
>> QueryLoader,cs.
>> We already have a series of classes to manage parameters (see
>> namespace NHibernate.Param).
>> Those classes was completely rewrote to give them a real effective usage.
>>
>> If you use those same classes even for Criteria we should have the whole
>> matter solved.
>> The work is not completely done because you have to review all Loader
>> inheritance (basically for ProcessFilters and some other stuff).
>> I found some dead code or, at least, some code not reached by our tests (see
>> AggregatedIndexCollectionSelectorParameterSpecifications).
>> For HQL/LINQ:
>> Each Parameter (class Parameter) is now marked for back-tracking in practice
>> a Parameter is created with the same ID of a IParameterSpecification.
>> In this way all SqlString modifiers (Dialect for pagination, HQL-Functions,
>> Filters) can move a Parameter around the query and we can always find them
>> later.
>> The certain-sequence of single SqlType (the result of a hql-parameter
>> "deploy") is required, so far, because:
>> IType.NullSafeSet(System.Data.IDbCommand , object, int, ISessionImplementor)
>> When you will modify that method to accept int[] you will be able to move
>> each single IDbParameter safely.
>> The work has some nice improvement (at least when the whole work will be
>> done):
>> - positional parameter can now appear before,after or mixed to
>> named-parameter, filters, pagination and so on
>> - various methods/classes can be removed (including a bunch of properties in
>> the dialect related to pagination)
>> - QueryParameters can be simplified (it should hold
>> just IParameterSpecification)
>> - named-parameters, even when used inside a filter. used more than once are
>> now translated in just one IDbParameter (you should find something else than
>> Parameter.ParameterPosition to influence the final name of the parameter)
>> Others TODO:
>> find all issues tickets related to parameters values assignations,
>> write/import the test, resolve the JIRA ticket.
>> P.S. I have used "you" and not "we"... but you already know the reason.
>> --
>> Fabio Maulo
>>
>>
>
