On Tue 06 Dec 2011 09:00:00 AM CST, David Mansfield wrote:
> I guess if you use session.load instead of session.get you won't get
> 10,000 queries over the network if batch fetching is enabled, which
> does exactly what the original issue discusses, it splits the "in"
> clause into chunks and execu
On 12/05/2011 04:44 PM, Steve Ebersole wrote:
> On Mon 05 Dec 2011 12:59:19 PM CST, David Mansfield wrote:
>> While I do agree wholeheartedly with most of what you say, I do think
>> it's unfair to say that the requirement is "fundamentally broken". That
>> label should be reserved for SQL itsel
> While I do agree wholeheartedly with most of what you say, I do think it's
> unfair to say that the requirement is "fundamentally broken". That label
> should be reserved for SQL itself ;-)
ok, let me rephrase "its a fundamentally broken way to do queries knowing how
majority of all relatio
On Mon 05 Dec 2011 12:59:19 PM CST, David Mansfield wrote:
> While I do agree wholeheartedly with most of what you say, I do think
> it's unfair to say that the requirement is "fundamentally broken". That
> label should be reserved for SQL itself ;-)
>
> If there is some opaque business rule R tha
While I do agree wholeheartedly with most of what you say, I do think
it's unfair to say that the requirement is "fundamentally broken". That
label should be reserved for SQL itself ;-)
If there is some opaque business rule R that operates on a large set of
input data, and that rule is impleme
> One technical (and probably way out of scope!) way to handle this would
> be to use a temp table, do a batch insert of the values, then change the
> " in (v1, v2, v3...)" to " in (select v from temp)".
I think I would rather hear people complain about query exceptions happening
when
they a
One technical (and probably way out of scope!) way to handle this would
be to use a temp table, do a batch insert of the values, then change the
" in (v1, v2, v3...)" to " in (select v from temp)".
On 12/01/2011 04:20 AM, Emmanuel Bernard wrote:
> Ah good point, I haven't thought of that prob
Ah good point, I haven't thought of that problem with query splitting
On 30 nov. 2011, at 22:20, Steve Ebersole wrote:
> Splitting is not always an option. Consider a predicate like:
>
> ... where a in (x1, ... x2000) and b in (y1, ... y2000) ...
>
> If you split this up, you will have misses.
Well, I would vote for making things simple, and leaving InExpression as
it is. BTW passing more than 1000 elements in IN clause sounds evil :).
Regards,
Lukasz
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman
Splitting is not always an option. Consider a predicate like:
... where a in (x1, ... x2000) and b in (y1, ... y2000) ...
If you split this up, you will have misses. Yes, it works if you can
keep it all in one query because you can structure it to maintain the
original semantics. However, pl
Also note that there is a limit for the query size globally in some vendors and
that people relieved from HHH-1123 cal fall into the second limit.
A solution would be for Hibernate to split one query into several but I'm not
sure I like the idea.
Emmanuel
On 29 nov. 2011, at 21:29, Łukasz Anton
Hi all!
Recently I had a closer look at HHH-1123 issue. This bug affects both -
Criteria API and HQL. I have introduced
Dialect#maximumInExpressionElements() method which returns maximum
number of allowed elements in a single SQL IN clause, or null treated as
infinite. The change of InExpressi
12 matches
Mail list logo
