Hi,
This looks promising and might be the groundwork for a feature we're
desperate for *Query Hints*.
As it stands, we had to disable the Parameter Sniffing feature in SQL
Server to work around some queries timing out due to bad Query Plans.
This is far from ideal and other queries suffer due to this.
*This is a concrete example of what we need to do:*
Session.Query<SomeEntity>()
.Where(...)
.Select(...)
.QueryHint(JoinType.Hash)
.ToList();
// The generated SQL would look like this:
SELECT ...
FROM Project INNER JOIN
OrganizationProject ON Project.ProjectID =
OrganizationProject.ProjectID
WHERE ...
OPTION (HASH JOIN)
My questions to you, Gunnar are:
- Have you made more progress on your implementation?
- Would you be willing to add support for these Query Hints (OPTION
MERGE JOIN, HASH JOIN) and optionally (LOOP JOIN, OPTIMIZE FOR UNKNOWN)?
If not, I would like to give it a shot (our backs are pressed against the
wall and we need a solution soon), but I'm not familiar with this part of
the NHibernate code base and would probably require some guidance on how
best to implement this.
Thank you for your time and consideration.
--
Daniel.
On Wednesday, September 30, 2015 at 3:26:34 AM UTC-4, Gunnar Liljas wrote:
>
> Do that. As the discussion there indicates, it's not a simple issue.
>
> —
> Sent from Mailbox <https://www.dropbox.com/mailbox>
>
>
> On Wed, Sep 30, 2015 at 7:14 AM, Peter Schojer <peter....@gmail.com
> <javascript:>> wrote:
>
>> Yes,
>> your proposed syntax is closer to what the database generates, that would
>> make more sense.
>> there is already a similar JIRA issue but for criteria: NH-1968
>> <https://nhibernate.jira.com/browse/NH-1968>
>>
>> Maybe simply update that ticket?
>>
>>
>>
>> Am Dienstag, 29. September 2015 23:16:19 UTC+2 schrieb Gunnar Liljas:
>>>
>>> It does come with a SetLockMode extension, yes. No, it does not fix
>>> that, nor do I think it should. If locking in combination with projection
>>> should work, I think the best syntax would be
>>>
>>> var result = (from e in db.Customers.WithLockMode(LockMode.Upgrade)
>>> where e.CompanyName == "Corp" select e.CustomerId).ToList();
>>>
>>> But it doesn't work, not even with HQL or Criteria, and implementing it
>>> would be slightly tricky, since the only lockmode making any sense in such
>>> a scenario is LockMode.Upgrade (I guess). A separate JIRA issue, perhaps?
>>>
>>> /G
>>>
>>> 2015-09-29 12:36 GMT+02:00 Peter Schojer <peter....@gmail.com>:
>>>
>>>> That's the commit with the SetLockMode extension? I am already waiting
>>>> for this one :-)
>>>>
>>>> Does this additional patch also fixes the problem that setlockmode
>>>> currently only works on selecting "full" objects?
>>>>
>>>> See my comment on the JIRA Ticket NH-2140 where the following query
>>>> fails:
>>>> var result = (from e in db.Customers where e.CompanyName == "Corp"
>>>> select e.CustomerId).SetLockMode(LockMode.Upgrade).ToList();
>>>>
>>>>
>>>>
>>>> Am Montag, 28. September 2015 17:42:36 UTC+2 schrieb Gunnar Liljas:
>>>>>
>>>>> So, to keep the momentum going, any favored paths forward? I don't
>>>>> mind the ResultOperators that much, as long as they are removed. They do
>>>>> however become part of the expression cache key, unless a specifically
>>>>> ignored during that process.
>>>>>
>>>>> Also, it was encouraging to get a response to my question. I wish
>>>>> there was more activity (or at least more active communication) regarding
>>>>> NH core development.
>>>>>
>>>>> /G
>>>>>
>>>>> 2015-09-28 9:42 GMT+02:00 Gunnar Liljas <gunnar...@gmail.com>:
>>>>>
>>>>>> OK, interesting. A similar idea but a different approach. It does
>>>>>> remove the ResultOperators though, which is a fair compromise.
>>>>>>
>>>>>> /G
>>>>>>
>>>>>> 2015-09-28 8:33 GMT+02:00 Michael Ketting <michael...@rubicon.eu>:
>>>>>>
>>>>>>> Hi Gunnar!
>>>>>>>
>>>>>>> EntityFramework is going a similiar route with a
>>>>>>> QueryAnnotationResultOperator they use to collect the annotations.
>>>>>>>
>>>>>>> https://github.com/aspnet/EntityFramework/blob/dev/src/EntityFramework.Core/Query/Internal/QueryAnnotationExtractor.cs
>>>>>>>
>>>>>>> That's actually one of the ideas I'm thinking of adopting for
>>>>>>> re-linq's own SQLBackend, too. For now, the ResultOperators certainly
>>>>>>> are
>>>>>>> the easiest way to accomplish this.
>>>>>>>
>>>>>>> Best regards, Michael
>>>>>>>
>>>>>>> On Monday, September 28, 2015 at 7:38:33 AM UTC+2, Alexander Zaytsev
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Gunnar,
>>>>>>>>
>>>>>>>> This looks very good. I think this can be simplified if we omit
>>>>>>>> these operations (cacheable, timeout, etc) from a query at all.
>>>>>>>>
>>>>>>>> I think this can be done by casting inside these methods (as EF
>>>>>>>> does sometimes) to the INHibernateQueriable (or similar interface) to
>>>>>>>> set
>>>>>>>> options.
>>>>>>>>
>>>>>>>> What do you think?
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>> Alexander
>>>>>>>>
>>>>>>>> On Mon, Sep 28, 2015 at 2:00 AM, Gunnar Liljas wrote:
>>>>>>>>
>>>>>>>>> Hi!
>>>>>>>>>
>>>>>>>>> I just made a commit (not a pull request, I'm not sure it's quite
>>>>>>>>> ready) with a new approach to query options in Linq queries. Instead
>>>>>>>>> of
>>>>>>>>> dealing with results operators for things that are actually not a
>>>>>>>>> part of
>>>>>>>>> the query, I made an expression visitor that extracts the query
>>>>>>>>> options
>>>>>>>>> from the query AND removes them. The options are applied to the
>>>>>>>>> parsed
>>>>>>>>> query.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://github.com/gliljas/nhibernate-core/commit/1655320149385c96c64fd56598e9253621ba0da9
>>>>>>>>>
>>>>>>>>> There was one major hurdle, and that was to omit these options if
>>>>>>>>> they occur in a subquery. Currently the visitor solves this (or does
>>>>>>>>> it?)
>>>>>>>>> by detecting when the first chain of Call expressions is done, but of
>>>>>>>>> course it would be more convenient to use Relinq for this. But that
>>>>>>>>> happens
>>>>>>>>> later in the chain than currently feasible.
>>>>>>>>>
>>>>>>>>> It's more a proof of concept, so I would very much like some
>>>>>>>>> feedback.
>>>>>>>>>
>>>>>>>>> /Gunnar
>>>>>>>>>
>>>>>>>>>
>>
>
--
---
You received this message because you are subscribed to the Google Groups
"nhibernate-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to nhibernate-development+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
