Hints can be specified on a query level or on a join level.

Thanks,

Leonid

Can you give us an example of the SQL in this case?

---

EntitySpaces | Twitter | BLOG | Please honor our Software License

I added this request to our enhancement tracking system, but here are my thoughts as to its priority:

1) Hints are not part of the SQL spec. Heck, INDEXes are not part of the spec. Consequently, each database vendor has completely different implementations and keywords.

2) Using hints is the exception rather than the rule. They require a complete understanding of the execution plan, and how the hint will improve upon what the vendor's optimizer provides. Improper use of hints can even hurt the performance of a query.

3) EntitySpaces already provides several means for implementing database-specific syntax within custom Loads for rarely used implementations that only apply to specific queries.

With limited time and resources, and scores of suggestions that could significantly improve productivity for a wider base of users, I think this is going to end up pretty low on the list. But, I'm willing to listen to arguments to the contrary.

---

David Neal Parsons
www.entityspaces.net

My problem is that I just found a SQL Server query hint that helps me to optimize my huge ES query. The query is not static, I build it at runtime, I like the flexibility ES provides in this matter.

I completely understand your concerns and it's hard for me to argue because I agree hints are probably touching just one customer out of a thousand. What I have in mind is to put your thoughts in a direction of how to make custom sql injections into the final select statement generated by EntitySpaces. You already provide '<..>' syntax for using in selects and order by clauses, but it's not always sufficient. What I'd really like to see is the following:

1. Expose the final SQL statement (as a string) to the caller BEFORE actually executing it. A virtual method in the esDynamicQuery class would be great for this purpose. Let the developer to make a change to this string, if necessary. This would be the ultimate flexibility.

2. Provide a virtual method in the esDynamicQuery class that let's to intercept different stages of the final query construction. Something like OnQueryBuild(QueryBuildArgs args) method with possible different inputs, like building a select clause, building a join, building a from clause, etc.

What do you think? 

Thanks,

Leonid

Ye, I agree with leonidbogdanov.

Expose the final SQL statement (as a string) to the caller BEFORE actually executing it will be the ultimate, but

maybe the security with possible sql injections could be a disaster.  Anyway, The idea is great.