April 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Commented: (HHH-971) ConcurrentModificationException with <many-to-one property_ref="..."/> in a set of composite elements

by Woohoo (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-971?page=co... ] Woohoo commented on HHH-971: ---------------------------- the problem didn't resolve? > ConcurrentModificationException with <many-to-one property_ref="..."/> in a set of composite elements > ----------------------------------------------------------------------------------------------------- > > Key: HHH-971 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-971 > Project: Hibernate Core > Issue Type: Bug > Components: core > Environment: Hibernate 3.1 beta 3, Java 1.4.2_08 > Reporter: Emmanuel Bourg > Assignee: Diego Plentz > > I tried to drop the latest 3.1-beta3 jar in my application currently working with hibernate 3.0.5 to test the new features and found out that an exception is now thrown when the SessionFactory is build : > java.util.ConcurrentModificationException > at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:448) > at java.util.AbstractList$Itr.remove(AbstractList.java:433) > at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1006) > at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1120) > at myapp.dao.impl.hibernate.SessionManager.init(SessionManager.java:74) > I tracked down the issue to the mapping of a many-to-one association using a property-ref inside a set of composite elements. The mapping generating this error looks like this: > <set name="children" table="CHILD"> > <key column="PARENT_ID"/> > <composite-element class="Child"> > <many-to-one name="foo" column="FOO" property-ref="alternateId"/> > </composite-element> > </set> > A many-to-one association with a property-ref outside a composite element didn't cause this exception. -- 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, 11 months

1
0
0 / 0

[Hibernate-JIRA] Created: (OGM-53) Upgrade to Hibernate Search 3.4.0.Final

by Sanne Grinovero (JIRA)

Upgrade to Hibernate Search 3.4.0.Final --------------------------------------- Key: OGM-53 URL: http://opensource.atlassian.com/projects/hibernate/browse/OGM-53 Project: Hibernate OGM Issue Type: Task Components: query Affects Versions: 1.0-next Reporter: Sanne Grinovero Assignee: Sanne Grinovero -- 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, 11 months

1
2
0 / 0

[Hibernate-JIRA] Created: (OGM-55) Upgrade to Infinispan 5.0.0.CR1

by Sanne Grinovero (JIRA)

Upgrade to Infinispan 5.0.0.CR1 ------------------------------- Key: OGM-55 URL: http://opensource.atlassian.com/projects/hibernate/browse/OGM-55 Project: Hibernate OGM Issue Type: Task Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Minor Fix For: 3.0.0.Alpha1 -- 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, 11 months

2
1
0 / 0

[Hibernate-JIRA] Created: (OGM-54) Upagrade to JBoss Transactions 4.15.0.Final

by Sanne Grinovero (JIRA)

Upagrade to JBoss Transactions 4.15.0.Final ------------------------------------------- Key: OGM-54 URL: http://opensource.atlassian.com/projects/hibernate/browse/OGM-54 Project: Hibernate OGM Issue Type: Task Components: core Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Minor -- 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, 11 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2931) Criteria.setMaxResults() filters children with fetch="join"

by Mattias Jiderhamn (JIRA)

Criteria.setMaxResults() filters children with fetch="join" ----------------------------------------------------------- Key: HHH-2931 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2931 Project: Hibernate3 Issue Type: Bug Components: query-criteria Affects Versions: 3.2.5 Reporter: Mattias Jiderhamn Assume class Parent with a collection of children that is mapped with fetch="join", then use a Criteria to find a specific Parent using setMaxResults(1).uniqueResult(). The child collection of the returned Parent will only hold 1 element, despite how many actual matching rows the child table has in the databasen. In this case, the fetch="join" needs to be ignored, and a separate query needs to be issued to fetch the children. This issue may very well be related to HHH-2049. -- 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, 11 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3807) Adding a restriction to a many-to-one entity in Criteria query causes Join fetching

by Jonathan Gordon (JIRA)

Adding a restriction to a many-to-one entity in Criteria query causes Join fetching ----------------------------------------------------------------------------------- Key: HHH-3807 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3807 Project: Hibernate Core Issue Type: Bug Components: query-criteria Affects Versions: 3.3.1 Environment: Hibernate 3.3.1GA Sql Server 2005 Reporter: Jonathan Gordon Priority: Minor When performing a criteria query that includes a restriction on a many-to-one entity, the associated entity is fetched eagerly, as if FetchMode were set to "JOIN". Explicitly setting the FetchMode to "SELECT" does not override this behavior. For instance, this criteria query: Criteria criteria = persistenceService.getCriteria(MailingParcel.class) .createAlias("mailingCampaign", "mc") .add(Restrictions.ge("mc.id", 1)) .setMaxResults(10); Yields the following sql: select top 10 this_.ID as ID17_1_, this_.KEYCODE as KEYCODE17_1_, this_.CAMPAIGN_ID as CAMPAIGN3_17_1_, this_.MAILING_LIST_MAILING_ID as MAILING4_17_1_, this_.COUNTRY_LE_ID as COUNTRY5_17_1_, this_.MATCH_ADDRESS as MATCH6_17_1_, this_.ADDRESS as ADDRESS17_1_, this_.MATCH_NAME as MATCH8_17_1_, this_.FIRST_NAME as FIRST9_17_1_, this_.LAST_NAME as LAST10_17_1_, this_.ZIP_CODE asZIP11_17_1_, this_.CITY as CITY17_1_, this_.STATE as STATE17_1_, this_.COMPANY as COMPANY17_1_, mc1_.ID as ID6_0_, mc1_.NOTE as NOTE6_0_, mc1_.NAME as NAME6_0_, mc1_.DATE_CREATED as DATE5_6_0_, mc1_.DATE_MODIFIED as DATE6_6_0_, mc1_.START_DATE as START7_6_0_, mc1_.SOURCE_FILE_NAME as SOURCE8_6_0_, mc1_.ORDINAL as ORDINAL6_0_, mc1_.KEYCODE_SUFFIX as KEYCODE10_6_0_, mc1_.MATCH_CATALOG_ID as MATCH11_6_0_, mc1_.ADDRESS_IMPORT_DATE as ADDRESS12_6_0_ from MATCH_MAILING_CAMPAIGN this_ inner join MATCH_CAMPAIGN_INFO mc1_ on this_.CAMPAIGN_ID=mc1_.ID where mc1_.ID>=1 However, removing the restriction yields the following sql: select top 10 this_.ID as ID17_0_, this_.KEYCODE as KEYCODE17_0_, this_.CAMPAIGN_ID as CAMPAIGN3_17_0_, this_.MAILING_LIST_MAILING_ID as MAILING4_17_0_, this_.COUNTRY_LE_ID as COUNTRY5_17_0_, this_.MATCH_ADDRESS as MATCH6_17_0_, this_.ADDRESS as ADDRESS17_0_, this_.MATCH_NAME as MATCH8_17_0_, this_.FIRST_NAME as FIRST9_17_0_, this_.LAST_NAME as LAST10_17_0_, this_.ZIP_CODE as ZIP11_17_0_, this_.CITY as CITY17_0_, this_.STATE as STATE17_0_, this_.COMPANY as COMPANY17_0_ from MATCH_MAILING_CAMPAIGN this_ Performing the original query in its HQL analog does not have this problem. -- 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, 11 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-2544) Create the EntityPersisters in order based on Inheritance hierarchy

by Shawn Clowater (JIRA)

Create the EntityPersisters in order based on Inheritance hierarchy ------------------------------------------------------------------- Key: HHH-2544 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2544 Project: Hibernate3 Issue Type: New Feature Components: core Affects Versions: 3.2.3 Reporter: Shawn Clowater Priority: Minor I have a bit of what might seem to be an odd request. I had run into a scenario where filters on my mappings that were part of a Single Table hierarchy were not getting into the configuration and it turned out it was based on the order that the EntityPersisters were being created as we've doing some minor magic with Custom EntityPersisters for filters. In our case we have a filter template where the filter is pretty much the same for each class that implements it except for the table and key name used in the filter. So, rather than define this annotation everywhere (we had previously been using xdoclet to generate it for the hbm mappings) we pushed the logic into a Custom Persister. So, essentially as it is building the EntityPersister we intercept the PersistentClass before it calls the super() constructor and add our required filters on the PersistantClass (in its FilterMap) before it gets passed up. This is done like this because by the time it gets to the AbstractEntityPersister's constructor it uses the filterMap to construct the FilterHelper and then you're done as you have no access to change that after it is built. So, in the Inheritance case any subclasses that are built before the main root class will not have the filters that we inject during the construction of our Custom Entity Persisters. I have temporarily worked around it by changing the Subclasses getFilterMap() method to not only return the filters from the Parent class but also from the class itself. Now, normally you can't define the filter on the subclass but I can through the persister. What I'd like to do is: Make the persister class for the subclasses a 'standard' persister that doesn't add any filters to the subclass. Still have my root class' entity persister adding the filters. But have the Entity Persisters built in hierarchal order in the SessionFactoryImpl. Since they are being built in any given order right now, I can't see an issue with providing some order to them, something like the AnnotationBinder does. -- 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, 11 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HV-468) Determine whether a property is indexed based on the runtime not static type

by Hardy Ferentschik (JIRA)

Determine whether a property is indexed based on the runtime not static type ---------------------------------------------------------------------------- Key: HV-468 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-468 Project: Hibernate Validator Issue Type: Bug Components: engine Affects Versions: 4.2.0.Beta2 Reporter: Hardy Ferentschik Fix For: 4.2.0.Final from the mailing list: {quote} there was an interesting question on the Validator forum (https://forum.hibernate.org/viewtopic.php?f=9&t=1010626&start=0) which IMO boils down to the question whether the static or the runtime type of an association should be considered when creating property paths in case of cascading validations. An example: {code} class Foo { private Collection<Bar> bar1 = new ArrayList<Bar>(); private List<Bar> bar2 = new ArrayList<Bar>(); } {code} When validating an instance of Foo (which has invalid elements in bar1/bar2) with HV, the resulting property path node for bar1 would be iterable but not indexable ("bar1[]"), while the property path node for bar2 would be iterable and indexable ("bar2[123]"). This is that way because the static type of bar1/bar2 (Collection vs. List) is considered when building the nodes, and not the runtime type (ArrayList in both cases). That said, basing the path on the runtime type instead would seem reasonable to me, too (as for instance the constraints to validate are also determined based on the runtime type of references). I scanned through the BV spec. (section 4.5) but didn't find a clear answer which approach should be followed. Are there any opinions on that? {quote} -- 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, 11 months

2
3
0 / 0

[Hibernate-JIRA] Commented: (HHH-1496) A new dialect is required for MySQL NDB clustered table types

by Daniel Serodio (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1496?page=c... ] Daniel Serodio commented on HHH-1496: ------------------------------------- Any update on this issue? > A new dialect is required for MySQL NDB clustered table types > ------------------------------------------------------------- > > Key: HHH-1496 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1496 > Project: Hibernate Core > Issue Type: Improvement > Components: core > Affects Versions: 3.1.2 > Reporter: Darran Lofthouse > Assignee: Juraci Paixao Krohling > Fix For: 3.5.x > > Attachments: HHH-1496.diff > > > A new dialect is required for MySQL NDB clustered table types > http://dev.mysql.com/doc/refman/5.0/en/create-table.html > Either ENGINE=NDB or ENGINE=NDBCLUSTER > Also FYI ENGINE is the prefered way of specifying the type over TYPE so MySQLMyISAMDialect and MySQLInnoDBDialect could also be updated to use ENGINE -- 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, 11 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6163) Need to fix location of envers integrator service file

by Steve Ebersole (JIRA)

Need to fix location of envers integrator service file ------------------------------------------------------ Key: HHH-6163 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6163 Project: Hibernate Core Issue Type: Bug Components: envers Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 4.0.0.Alpha3 -- 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, 11 months

1
1
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 April 2011