June 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-6345) sql like restriction and projection on a same field does not work (database -- mqsql)

by MANISH (JIRA)

sql like restriction and projection on a same field does not work (database -- mqsql) ------------------------------------------------------------------------------------- Key: HHH-6345 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6345 Project: Hibernate Core Issue Type: Bug Components: query-criteria Affects Versions: 3.5.6 Environment: version-hibernate-3.5.6 database-Mqsql 5.1.54 Reporter: MANISH I encountered this problem when I put group by on two columns of a table using hibernate criteria.I want to access some columns from the table using projection and I put the like restriction on the same columns using hibernate criteria that I want to access through projection. When I fetch the list I get the sql grammar exception. I track the issue, I found that the hibernate tries to put like clause on the column alias name which is not possible, ultimately hibernate is generating wrong sql query. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6340) Revisit EntityBindingState

by Steve Ebersole (JIRA)

Revisit EntityBindingState -------------------------- Key: HHH-6340 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6340 Project: Hibernate Core Issue Type: Task Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 4.0.0.Beta2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-6343) Remove JavaClassNameResolver because it is not used

by Gail Badner (JIRA)

Remove JavaClassNameResolver because it is not used --------------------------------------------------- Key: HHH-6343 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6343 Project: Hibernate Core Issue Type: Task Components: core Reporter: Gail Badner Assignee: Gail Badner Fix For: 3.6.6 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-6342) Add EntityModeEntitySpecifics.getTuplizerClass()

by Gail Badner (JIRA)

Add EntityModeEntitySpecifics.getTuplizerClass() ------------------------------------------------ Key: HHH-6342 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6342 Project: Hibernate Core Issue Type: Sub-task Components: core Affects Versions: 4.0.0.Beta1 Reporter: Gail Badner Assignee: Gail Badner -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-6341) Add AttributeBinding.isBasicPropertyAccessor()

by Gail Badner (JIRA)

Add AttributeBinding.isBasicPropertyAccessor() ---------------------------------------------- Key: HHH-6341 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6341 Project: Hibernate Core Issue Type: Sub-task Components: core Reporter: Gail Badner Assignee: Gail Badner Fix For: 4.0.0.Beta2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-6320) Add boolean values and getters to EntityIdentifier indicating if an ID is embedded or "identifier mapper"

by Gail Badner (JIRA)

Add boolean values and getters to EntityIdentifier indicating if an ID is embedded or "identifier mapper" --------------------------------------------------------------------------------------------------------- Key: HHH-6320 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6320 Project: Hibernate Core Issue Type: Sub-task Components: core Reporter: Gail Badner Assignee: Gail Badner Fix For: 4.0.0.next -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-6319) Add getter for attribute node name

by Gail Badner (JIRA)

Add getter for attribute node name ---------------------------------- Key: HHH-6319 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6319 Project: Hibernate Core Issue Type: Sub-task Components: core Reporter: Gail Badner Assignee: Gail Badner Fix For: 4.0.0.next Attribute node name is currently in AbstractAttributeBinding.nodeName, so I'll tentatively put the getter in AbstractAttributeBinding as well. Might be better to put nodeName and its getter in Attribute (or AttributeBinding.dom4jAttributeSpecifics???) instead, to be consistent with Entity. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-6321) Add org.hibernate.metamodel.binding.CascadeType.getCascadeStyle()

by Gail Badner (JIRA)

Add org.hibernate.metamodel.binding.CascadeType.getCascadeStyle() ----------------------------------------------------------------- Key: HHH-6321 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6321 Project: Hibernate Core Issue Type: Sub-task Reporter: Gail Badner Assignee: Gail Badner -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

1
2
0 / 0

[Hibernate-JIRA] Commented: (HHH-1775) collection batch fetching

by Guenther Demetz (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1775?page=c... ] Guenther Demetz commented on HHH-1775: -------------------------------------- I agree, the collection batch fetching algorithm must be reviewed. As it is implemented now, it gains performance only on small persistent contexts. As soon you have some hundred persistent collections in the context, BetchFetchQueue.getCollectionBatch() does take more time to calculate the batch than it would cost to execute the queries without batch fetching. > collection batch fetching > ------------------------- > > Key: HHH-1775 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1775 > Project: Hibernate Core > Issue Type: Improvement > Components: core > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Priority: Minor > Fix For: hql+collection > > > I have code local on my box to support "peeking" into the second level cache when determining whether to add a particular entity/collection key to a batch load request. If the given key is contained in the second level cache, then do not batch fetch the entity/collection as it will be initialized from second level cache on access. > However, there are still large inefficiencies when performing this for collections; the biggest of which currently is the fact that we retreive a IdentityMap.entrySet for each and ever call to determine a collectiomn fetch batch. For performance reasons, we should align this with how entity batches are handled where the entity keys considered to be "batch loadable" are tracked seperately on the BatchFetchQueue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6339) Get rid of system-level configuration properties, make all properties session factory scoped

by Leonid Kosmylev (JIRA)

Get rid of system-level configuration properties, make all properties session factory scoped -------------------------------------------------------------------------------------------- Key: HHH-6339 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6339 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 3.6.0 Reporter: Leonid Kosmylev Some of the configuration properties are system-level properties. This fact is documented for example here: http://docs.jboss.org/hibernate/core/3.3/reference/en/html/session-config... It would be a great improvement if these properties become session factory scoped instead of system-level. I actually think the current behavior is pretty much a bug. Reason? Some creative people decided to use Hibernate as the JPA implementation in their JEE offering. The very same people made it damn impossible to deploy a copy of hibernate as part of a JEE application. It means that now *all* JEE applications deployed in that server *share* Hibernate classes *and* system-level properties. There are situations when the applications need to specify different values for system-level properties. Ooops, it can't be done. I do not know if it is possible to get rid of all system-level properties. One that I really would like to see session scoped is 'hibernate.jdbc.use_streams_for_binary'. There is also a closed bug http://opensource.atlassian.com/projects/hibernate/browse/HB-646 which I unfortunately cannot reopen. There is no reason to keep this property system-level. Documentation? Document the new behavior and then "As per the doco, this is a session-factory property". An architectural issue? I do not know what kind of an architectural issue existed in 2.1.1 timeframe, but with the latest changes around types I do not see any. I am actually running with a patched Hibernate (only for 'hibernate.jdbc.use_streams_for_binary'), and the patch changes just 2 lines in org.hibernate.type.AbstractStandardBasicType. This is just a functionality change, I realize that the patch would also need to change some other classes, deprecate things here and there, and update the documentation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues June 2011