Re: [hibernate-dev] HHH-1123 - Cannot put more than 1000 elements in a InExpression
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 Antoniak wrote: > 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 InExpression was very easy. However, fixing this > bug for HQL queries requires modification of ParameterMetadata > (namedDescriptorMap cannot remain unmodifiable), as well as > AbstractQueryImpl (queryString). As I don't see any other solution, I > wanted to ask you guys for suggestions. Is it the only possible way of > fixing this issue? Finally, shall we really fix this? This is a DB > vendor limitation, but 40 user gave their vote for it. > > Regards, > Lukasz Antoniak > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Pull request for HHH-6865
I created a pull request for HHH-6865. IMO, this should be fixed for the next CR. https://hibernate.onjira.com/browse/HHH-6865 https://github.com/hibernate/hibernate-core/pull/232 Please take a look and merge if it looks OK. Thanks, Gail ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] any suggestion about how to fix HHH-5992?
Not sure when you sent this out, but I already fixed this (my) yeasterday. The only real option, IMO, is to throw an exception. As long as we are tied to pulling resultset values based on column name this is going to be a situation that we simply cannot reasonably support. Modifying the sql query is extremely difficult. On Tue 29 Nov 2011 11:37:59 AM CST, Max Rydahl Andersen wrote: >> I agree we should not do any magic on a native query; but following >> this reasoning just anything should be possible, and I wouldn't expect >> Hibernate to apply such magic to the results either. >> Why is it even looking at names in the resultset? As a user I'd want >> it to just return the same ordered sequence of values. > > At the time of original implementation there wasn't any other way to do the > mapping as I recall. > > I guess in this very special case (no scalars, nor entity mappings) adding on > the query it could be handled differently. > > Note though that we need to ensure if you apply a result transformer to this > query it will actually return something sensible > (i.e. named aliases for a map vs just indexes) > > The rearranging of hibernate core might allow for handling this now but I'm > not uptodate on that. > > /max > >> I would consider it very important to allow a full "jdbc fallback" >> experience, otherwise instead of being a nice tool it becomes an >> impediment and users will rightfully hate you. >> >> Sanne >> >> On 29 November 2011 15:25, Max Rydahl Andersen >> wrote: >>> the original idea of the native sql approach is to avoid/reduce doing >>> anything magical with the query since >>> there is no way to fix these generally without a full sql parser. >>> >>> So I would say it works as expected. >>> >>> /max >>> >>> On Nov 29, 2011, at 11:59, Strong Liu wrote: >>> T_User id username 1stliu 2gail for example a native query sql "select v1.username, v2.username from T_User v1, T_User v2 where v1.id = '1' and v2.id = '2'" but the query returns ["stliu", "stliu"] instead of the expected ["stliu", "gail"] this is because hibernate uses column alias (in this case, both are "username") to get the result from ResultSet, and since the two result in RS are all keyed by "username" should we generate a alias for each like hql does? - Best Regards, Strong Liu http://about.me/stliu/bio ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>> /max >>> http://about.me/maxandersen >>> >>> >>> >>> >>> ___ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > > /max > http://about.me/maxandersen > > > > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate Filters and EntityManager.find
What you are doing is called multi-tenancy. Hibernate 4 has more explicit support for multi-tenant data. Unfortunately 4.0 only supports cases where the schema is replicated on multiple databases/schemas. There will also be support for discrimination-based multi-tenancy at some point in 4.x (4.1 or 4.2). If you want to help develop that feature, that would be great. However, I am not going to change the way/places that filters are applied. They work exactly as intended. On Tue 29 Nov 2011 11:24:19 AM CST, Jason Clawson wrote: > Hi everyone. I know that Hibernate session filters do not apply to > find/load operations because the assumption was made that if you know the > ID of the entity you wish to load, why tack on the extra WHERE condition. > Please let me explain my use case for filters and illustrate why this > assumption is incorrect. > > We use filters to do data separation. For example, separating one > customers data from another's. We also have other filters that do finer > grained object visibility conditions. But lets take a look at customer > data separation since its the easiest to understand. The advantage of > doing customer data separation in this way is that developers don't need to > think about it. It just works, and it works *automatically*. The problem > comes in when you want to do something like em.find(User.class, 1). No > WHERE clause is attached to the SQL statement. Yes, I know the ID, but I > really want to tack on to the WHERE clause "AND customerId = 3" to make > sure that someone isn't fuzzing the ID parameter to try and get at another > customer's data. > > The workaround we have is another mechanism that validates the entity in a > PostLoad entity listener and throws an exception if the customerId != the > request's customerId. This is "ok" for the simple example I laid out here. > However, we now have many more filters that implement complex visibility > rules based on subselects and oracle CONNECT BY clauses which cannot be > implemented using a simple equality check in java. The best, most > performant, solution is to be able to apply the filter clause to the > EntityManager.find operation. > > What is your take on this? > > Thanks, > > Jason Clawson > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate Filters and EntityManager.find
Thanks for your response. Yes it is multi-tenency however that's just 1 filter of the 8 we have. We use it for more than just that. For example, within a single customer, there are object visibility permissions based on a complex interaction between roles and a tree with inheritance. Whether or not a user can see a particular object is determined by a recursive tree traversing oracle CONNECT BY clause. These different visibility filters we have are only applied to specific entities. Filters are the right mechanism to handle this as they contain all the necessary semantics We can disable them for certain requests if the current user is an admin, or we can even do it for a few specific queries with our sudo concept. They can be applied to specific entities and multiple filters can be applied to the same entity. And since a relatively recent release they affect DML operations (I had to patch hibernate to do this a while ago). The multitenency in 4.0 won't work for us. We have a single schema based multi tenency. The discrimination based one probably won't work either because we need to be able to write a custom SQL clause like we can in filters. It would work for customer data separation probably, but our other 7 filters can not be modeled in that way since they rely on some complex SQL clauses. I understand filters work as intended. Can you explain a little about why it was intended to ignore the active filters when doing a find? And why respecting the filters on a find is bad? Thanks, Jason Clawson Sent from my iPhone On Nov 30, 2011, at 7:30 AM, Steve Ebersole wrote: > What you are doing is called multi-tenancy. > > Hibernate 4 has more explicit support for multi-tenant data. Unfortunately > 4.0 only supports cases where the schema is replicated on multiple > databases/schemas. There will also be support for discrimination-based > multi-tenancy at some point in 4.x (4.1 or 4.2). If you want to help develop > that feature, that would be great. > > However, I am not going to change the way/places that filters are applied. > They work exactly as intended. > > > On Tue 29 Nov 2011 11:24:19 AM CST, Jason Clawson wrote: >> Hi everyone. I know that Hibernate session filters do not apply to >> find/load operations because the assumption was made that if you know the >> ID of the entity you wish to load, why tack on the extra WHERE condition. >> Please let me explain my use case for filters and illustrate why this >> assumption is incorrect. >> >> We use filters to do data separation. For example, separating one >> customers data from another's. We also have other filters that do finer >> grained object visibility conditions. But lets take a look at customer >> data separation since its the easiest to understand. The advantage of >> doing customer data separation in this way is that developers don't need to >> think about it. It just works, and it works *automatically*. The problem >> comes in when you want to do something like em.find(User.class, 1). No >> WHERE clause is attached to the SQL statement. Yes, I know the ID, but I >> really want to tack on to the WHERE clause "AND customerId = 3" to make >> sure that someone isn't fuzzing the ID parameter to try and get at another >> customer's data. >> >> The workaround we have is another mechanism that validates the entity in a >> PostLoad entity listener and throws an exception if the customerId != the >> request's customerId. This is "ok" for the simple example I laid out here. >> However, we now have many more filters that implement complex visibility >> rules based on subselects and oracle CONNECT BY clauses which cannot be >> implemented using a simple equality check in java. The best, most >> performant, solution is to be able to apply the filter clause to the >> EntityManager.find operation. >> >> What is your take on this? >> >> Thanks, >> >> Jason Clawson >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > -- > st...@hibernate.org > http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Pull request for HHH-6865
I am working on this one. Was going to use the opportunity to clean up some things in the LockingStrategy hierarchy and its users. On Wed 30 Nov 2011 08:01:11 AM CST, Gail Badner wrote: > I created a pull request for HHH-6865. > > IMO, this should be fixed for the next CR. > > https://hibernate.onjira.com/browse/HHH-6865 > https://github.com/hibernate/hibernate-core/pull/232 > > Please take a look and merge if it looks OK. > > Thanks, > Gail -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] any suggestion about how to fix HHH-5992?
On Nov 30, 2011, at 15:22, Steve Ebersole wrote: > Not sure when you sent this out, but I already fixed this (my) yeasterday. > The only real option, IMO, is to throw an exception. As long as we are tied > to pulling resultset values based on column name this is going to be a > situation that we simply cannot reasonably support. Modifying the sql query > is extremely difficult. Agreed - seems you throw only when duplicated aliases and with auto discovery - that seems like the best option yes. Might break existing queries though - but thats better than the silent bug problem. /max > > > > On Tue 29 Nov 2011 11:37:59 AM CST, Max Rydahl Andersen wrote: >>> I agree we should not do any magic on a native query; but following >>> this reasoning just anything should be possible, and I wouldn't expect >>> Hibernate to apply such magic to the results either. >>> Why is it even looking at names in the resultset? As a user I'd want >>> it to just return the same ordered sequence of values. >> >> At the time of original implementation there wasn't any other way to do the >> mapping as I recall. >> >> I guess in this very special case (no scalars, nor entity mappings) adding >> on the query it could be handled differently. >> >> Note though that we need to ensure if you apply a result transformer to this >> query it will actually return something sensible >> (i.e. named aliases for a map vs just indexes) >> >> The rearranging of hibernate core might allow for handling this now but I'm >> not uptodate on that. >> >> /max >> >>> I would consider it very important to allow a full "jdbc fallback" >>> experience, otherwise instead of being a nice tool it becomes an >>> impediment and users will rightfully hate you. >>> >>> Sanne >>> >>> On 29 November 2011 15:25, Max Rydahl Andersen >>> wrote: the original idea of the native sql approach is to avoid/reduce doing anything magical with the query since there is no way to fix these generally without a full sql parser. So I would say it works as expected. /max On Nov 29, 2011, at 11:59, Strong Liu wrote: > T_User > id username > 1stliu > 2gail > > for example a native query sql "select v1.username, v2.username from > T_User v1, T_User v2 where v1.id = '1' and v2.id = '2'" > > but the query returns ["stliu", "stliu"] instead of the expected > ["stliu", "gail"] > > this is because hibernate uses column alias (in this case, both are > "username") to get the result from ResultSet, and since the two result in > RS are all keyed by "username" > > > should we generate a alias for each like hql does? > > > - > Best Regards, > > Strong Liu > http://about.me/stliu/bio > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev /max http://about.me/maxandersen ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> /max >> http://about.me/maxandersen >> >> >> >> >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > -- > st...@hibernate.org > http://hibernate.org /max http://about.me/maxandersen ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] any suggestion about how to fix HHH-5992?
Well a long term solution is to move to resultset value extraction based on position rather than name. Which I believe we should do, but it wont happen any time soon. That would actually fix this problem. On Wed 30 Nov 2011 10:57:31 AM CST, Max Rydahl Andersen wrote: > > On Nov 30, 2011, at 15:22, Steve Ebersole wrote: > >> Not sure when you sent this out, but I already fixed this (my) yeasterday. >> The only real option, IMO, is to throw an exception. As long as we are tied >> to pulling resultset values based on column name this is going to be a >> situation that we simply cannot reasonably support. Modifying the sql query >> is extremely difficult. > > Agreed - seems you throw only when duplicated aliases and with auto discovery > - that seems like the best option yes. > > Might break existing queries though - but thats better than the silent bug > problem. > > /max > > >> >> >> >> On Tue 29 Nov 2011 11:37:59 AM CST, Max Rydahl Andersen wrote: I agree we should not do any magic on a native query; but following this reasoning just anything should be possible, and I wouldn't expect Hibernate to apply such magic to the results either. Why is it even looking at names in the resultset? As a user I'd want it to just return the same ordered sequence of values. >>> >>> At the time of original implementation there wasn't any other way to do the >>> mapping as I recall. >>> >>> I guess in this very special case (no scalars, nor entity mappings) adding >>> on the query it could be handled differently. >>> >>> Note though that we need to ensure if you apply a result transformer to >>> this query it will actually return something sensible >>> (i.e. named aliases for a map vs just indexes) >>> >>> The rearranging of hibernate core might allow for handling this now but I'm >>> not uptodate on that. >>> >>> /max >>> I would consider it very important to allow a full "jdbc fallback" experience, otherwise instead of being a nice tool it becomes an impediment and users will rightfully hate you. Sanne On 29 November 2011 15:25, Max Rydahl Andersen wrote: > the original idea of the native sql approach is to avoid/reduce doing > anything magical with the query since > there is no way to fix these generally without a full sql parser. > > So I would say it works as expected. > > /max > > On Nov 29, 2011, at 11:59, Strong Liu wrote: > >> T_User >> id username >> 1stliu >> 2gail >> >> for example a native query sql "select v1.username, v2.username from >> T_User v1, T_User v2 where v1.id = '1' and v2.id = '2'" >> >> but the query returns ["stliu", "stliu"] instead of the expected >> ["stliu", "gail"] >> >> this is because hibernate uses column alias (in this case, both are >> "username") to get the result from ResultSet, and since the two result >> in RS are all keyed by "username" >> >> >> should we generate a alias for each like hql does? >> >> >> - >> Best Regards, >> >> Strong Liu >> http://about.me/stliu/bio >> >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > /max > http://about.me/maxandersen > > > > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> >>> /max >>> http://about.me/maxandersen >>> >>> >>> >>> >>> ___ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> -- >> st...@hibernate.org >> http://hibernate.org > > /max > http://about.me/maxandersen > > > -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] any suggestion about how to fix HHH-5992?
> Well a long term solution is to move to resultset value extraction based on > position rather than name. Which I believe we should do, but it wont happen > any time soon. That would actually fix this problem. Yes, but you would still have the problem then for auto discovered scalar queries into a map. smaller corner case at least ;) /max > > > On Wed 30 Nov 2011 10:57:31 AM CST, Max Rydahl Andersen wrote: >> >> On Nov 30, 2011, at 15:22, Steve Ebersole wrote: >> >>> Not sure when you sent this out, but I already fixed this (my) yeasterday. >>> The only real option, IMO, is to throw an exception. As long as we are >>> tied to pulling resultset values based on column name this is going to be a >>> situation that we simply cannot reasonably support. Modifying the sql >>> query is extremely difficult. >> >> Agreed - seems you throw only when duplicated aliases and with auto >> discovery - that seems like the best option yes. >> >> Might break existing queries though - but thats better than the silent bug >> problem. >> >> /max >> >> >>> >>> >>> >>> On Tue 29 Nov 2011 11:37:59 AM CST, Max Rydahl Andersen wrote: > I agree we should not do any magic on a native query; but following > this reasoning just anything should be possible, and I wouldn't expect > Hibernate to apply such magic to the results either. > Why is it even looking at names in the resultset? As a user I'd want > it to just return the same ordered sequence of values. At the time of original implementation there wasn't any other way to do the mapping as I recall. I guess in this very special case (no scalars, nor entity mappings) adding on the query it could be handled differently. Note though that we need to ensure if you apply a result transformer to this query it will actually return something sensible (i.e. named aliases for a map vs just indexes) The rearranging of hibernate core might allow for handling this now but I'm not uptodate on that. /max > I would consider it very important to allow a full "jdbc fallback" > experience, otherwise instead of being a nice tool it becomes an > impediment and users will rightfully hate you. > > Sanne > > On 29 November 2011 15:25, Max Rydahl Andersen > wrote: >> the original idea of the native sql approach is to avoid/reduce doing >> anything magical with the query since >> there is no way to fix these generally without a full sql parser. >> >> So I would say it works as expected. >> >> /max >> >> On Nov 29, 2011, at 11:59, Strong Liu wrote: >> >>> T_User >>> id username >>> 1stliu >>> 2gail >>> >>> for example a native query sql "select v1.username, v2.username from >>> T_User v1, T_User v2 where v1.id = '1' and v2.id = '2'" >>> >>> but the query returns ["stliu", "stliu"] instead of the expected >>> ["stliu", "gail"] >>> >>> this is because hibernate uses column alias (in this case, both are >>> "username") to get the result from ResultSet, and since the two result >>> in RS are all keyed by "username" >>> >>> >>> should we generate a alias for each like hql does? >>> >>> >>> - >>> Best Regards, >>> >>> Strong Liu >>> http://about.me/stliu/bio >>> >>> ___ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> /max >> http://about.me/maxandersen >> >> >> >> >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> /max http://about.me/maxandersen ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>> -- >>> st...@hibernate.org >>> http://hibernate.org >> >> /max >> http://about.me/maxandersen >> >> >> > > -- > st...@hibernate.org > http://hibernate.org /max http://about.me/maxandersen ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HHH-1123 - Cannot put more than 1000 elements in a InExpression
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, please read the comments on that JIRA issue. For some databases, this restriction is not just on the number of elements in a in-list, but on the number of parameters overall. Splitting these 2 in-lists about into 4 does not address that. I commented on the issue that I am actually inclined to simply reject this one. In fact, I thought we already did. Maybe that was another earlier one? On Wed 30 Nov 2011 04:45:55 AM CST, Emmanuel Bernard wrote: > 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 Antoniak wrote: > >> 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 InExpression was very easy. However, fixing this >> bug for HQL queries requires modification of ParameterMetadata >> (namedDescriptorMap cannot remain unmodifiable), as well as >> AbstractQueryImpl (queryString). As I don't see any other solution, I >> wanted to ask you guys for suggestions. Is it the only possible way of >> fixing this issue? Finally, shall we really fix this? This is a DB >> vendor limitation, but 40 user gave their vote for it. >> >> Regards, >> Lukasz Antoniak >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HHH-1123 - Cannot put more than 1000 elements in a InExpression
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/listinfo/hibernate-dev
[hibernate-dev] Hibernate Core 4.0.0.CR7 Released
see http://in.relation.to/Bloggers/HibernateCore400CR7Release for more details - Best Regards, Strong Liu http://about.me/stliu/bio ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
