January 2007 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2284) HQL: selecting components inside components doesn't work

by Fabio Tudone (JIRA)

HQL: selecting components inside components doesn't work -------------------------------------------------------- Key: HHH-2284 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2284 Project: Hibernate3 Type: Bug Components: query-hql Versions: 3.1.2 Environment: Probably all. Tested with DB2, MySQL, HSQL + Tomcat, WAS5, DriverManager. Reporter: Fabio Tudone Priority: Critical Attachments: test.jar When using an entity with a component owning another component, as follows: <class name="org.test.hibernate.bug2455.MyEntity"> <composite-id> <key-property name="myKey"> <column name="myKey"/> </key-property> </composite-id> <component name="myComponent"> <property name="myValue"> <column name="myValue"/> </property> <component name="myInnerComponent"> <property name="myInnerValue"> <column name="myInnerValue"/> </property> </component> </component> </class> The following HQL query fails: "select e.myComponent.myInnerComponent from org.test.hibernate.bug2455.MyEntity e" with the following error: could not resolve property: myInnerComponent of: org.test.hibernate.bug2455.MyEntity -- 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

17 years, 5 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2300) Updated dialect for H2 database engine

by Thomas Mueller (JIRA)

Updated dialect for H2 database engine --------------------------------------- Key: HHH-2300 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2300 Project: Hibernate3 Type: Patch Components: core Versions: 3.2.1 Environment: H2 database engine Reporter: Thomas Mueller Attachments: H2Dialect.java Unfortunately, the column name of an information-schema table changed in the H2 database. Here is a new version of the dialect. -- 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

17 years, 5 months

2
3
0 / 0

[Hibernate-JIRA] Updated: (HHH-16) Explicit joins on unrelated classes

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-16?page=all ] Steve Ebersole updated HHH-16: ------------------------------ Fix Version: 3.3 (was: 3.2.2) Initial release of 3.3 will be merging of the HQL_ANTLR_2 branch and trunk. HQL_ANTLR_2 is the branch where all this HQL translator work has been happening. > Explicit joins on unrelated classes > ----------------------------------- > > Key: HHH-16 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-16 > Project: Hibernate3 > Type: New Feature > Components: core > Environment: Any > Reporter: David Lloyd > Assignee: Steve Ebersole > Fix For: 3.3 > > > It would be nice to be able to do explicit joins on unrelated classes with HQL: > (hope this renders correctly) > select empl, phone > from org.example.Employee empl > left outer join org.example.PhoneBook phone > on phone.lastName = empl.lastName > and phone.firstName = empl.firstName > where empl.salaryGrade > 10 > Note that this would also implicity solve HB-1089 because you could list join criteria that match what Hibernate would have chosen anyway (i.e., list a many-to-one relationship as a criteria explicitly). > Syntactically this could be disambiguated from the existing join syntax because the token after "join" is a class name rather than a property name. -- 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

17 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-1718) Have multiple bag fetches revert to subselect fetching for all but one of the bags

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1718?page=all ] Steve Ebersole updated HHH-1718: -------------------------------- Fix Version: hql+collection (was: 3.2.2) > Have multiple bag fetches revert to subselect fetching for all but one of the bags > ---------------------------------------------------------------------------------- > > Key: HHH-1718 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1718 > Project: Hibernate3 > Type: Improvement > Components: core, query-hql, query-criteria > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Fix For: hql+collection > > > Follow on to HHH-1413. Multiple bag fetches were simply disallowed as the resolution to that particular case in the interest of working around that issue. > The correct longer term solution is to not fetch all the bags at once, ideally reverting to subselect fetching for all but one of the bags. -- 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

17 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-1499) use subselect fetching for collection join fetches with DISTINCT or firstResult/maxRows

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1499?page=all ] Steve Ebersole updated HHH-1499: -------------------------------- Fix Version: hql+collection (was: 3.2.2) > use subselect fetching for collection join fetches with DISTINCT or firstResult/maxRows > --------------------------------------------------------------------------------------- > > Key: HHH-1499 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1499 > Project: Hibernate3 > Type: Improvement > Components: query-hql > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Fix For: hql+collection > > > As a follow on to HHH-1411and HHH-1412... > Both of those above were actually resolved by handling the DISTINCT-ion and/or firstResult/maxRows *in memory*. A better solution is to not honor the join fetch in these cases, perform the requested operation, and then get the requested join fectehd collections through subselect fetches. > As is, this would work as long as the collections have subselect fetching enabled in metadata, but would actually use immediate fetching (n+1) for any collections not defining subselect fetching in metadata. This is due to the way PersistenceContext.initializeNonLazyCollections() currently works. -- 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

17 years, 5 months

1
0
0 / 0

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

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1775?page=all ] Steve Ebersole updated HHH-1775: -------------------------------- Fix Version: hql+collection (was: 3.2.2) > collection batch fetching > ------------------------- > > Key: HHH-1775 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1775 > Project: Hibernate3 > 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

17 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-2371) enhancements to C3P0ConnectionProvider

by Steve Ebersole (JIRA)

enhancements to C3P0ConnectionProvider -------------------------------------- Key: HHH-2371 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2371 Project: Hibernate3 Type: Task Components: core Versions: 3.2.0.cr4 Reporter: Steve Ebersole Assigned to: Max Rydahl Andersen Priority: Critical Fix For: 3.2.2 c3p0-0.9.0.4 apparently has a connection leak (case 00010976) that is fixed in c3p0-0.9.1-pre6. will though have to look into if it is a drop-in replacement because of the following excerpt from the relaes notes: Deprecated PoolConfig, and began implementation of new C3P0Config approach to configuration. -- 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

17 years, 5 months

1
4
0 / 0

[Hibernate-JIRA] Created: (HHH-2032) consider updating c3p0 because of connection leak bug

by Max Rydahl Andersen (JIRA)

consider updating c3p0 because of connection leak bug ----------------------------------------------------- Key: HHH-2032 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2032 Project: Hibernate3 Type: Task Components: core Versions: 3.2.0.cr4 Reporter: Max Rydahl Andersen Priority: Critical Fix For: 3.2.0.ga c3p0-0.9.0.4 apparently has a connection leak (case 00010976) that is fixed in c3p0-0.9.1-pre6. will though have to look into if it is a drop-in replacement because of the following excerpt from the relaes notes: Deprecated PoolConfig, and began implementation of new C3P0Config approach to configuration. -- 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

17 years, 5 months

4
12
0 / 0

[Hibernate-JIRA] Created: (HHH-2372) Allow tooling to create Settings via SettingsFactory without contacting the db

by Max Rydahl Andersen (JIRA)

Allow tooling to create Settings via SettingsFactory without contacting the db ------------------------------------------------------------------------------ Key: HHH-2372 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2372 Project: Hibernate3 Type: Improvement Components: core Versions: 3.2.1 Reporter: Max Rydahl Andersen -- 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

17 years, 5 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2370) Xml-persisted empty string are interpreted as null value

by Daniele Castagna (JIRA)

Xml-persisted empty string are interpreted as null value -------------------------------------------------------- Key: HHH-2370 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2370 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.2 Environment: All hibernate version, on all platform. Reporter: Daniele Castagna Priority: Minor Attachments: HEmptyString.tar.gz NullableType.Object fromXMLString(String xml, Mapping factory) method returns null if the string is an empty string (string with a length of 0). This creates some problems when you use xml persistence to export or import empty string property with the not-null costraint. Look at the attachment simple project (or here: http://forum.hibernate.org/viewtopic.php?t=969755 ) for an example that will throw an unexpected exception. This problem could be easily fixed removing the "|| xml.length()==0" boolean expression from the fromXMLString method. I think that it would be better not only with strings but even with other types; for example an xml tag that should be interpreted as an Integer and contains an empty string should throw an exception, and should not return a null value. The null value is already represented by the absence of the xml tag. -- 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

17 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues January 2007