April 2007 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Commented: (HHH-1473) hbm2ddl validate seems to fail when views are involved

by Shadow X (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1473?page=c... ] Shadow X commented on HHH-1473: ------------------------------- I believe the fix is simple, although I do not know if it will break anything else. See this page: http://www.cs.helsinki.fi/u/vkuokkan/gradu/aeonstore/tools/hibernate.html... I tried compiling Hibernate Core 3.2.3 with that change and it allowed validation to work. > hbm2ddl validate seems to fail when views are involved > ------------------------------------------------------ > > Key: HHH-1473 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1473 > Project: Hibernate3 > Issue Type: Bug > Components: metamodel > Affects Versions: 3.1 > Reporter: Emmanuel Bernard > Priority: Minor > > http://forum.hibernate.org/viewtopic.php?t=955341&start=0&postdays=0&post... > CategoryRanking is a view > org.hibernate.HibernateException: Missing table: CategoryRating > at org.hibernate.cfg.Configuration.validateSchema(Configuration.java:953) > at org.hibernate.tool.hbm2ddl.SchemaValidator.validate(SchemaValidator.java:116) > at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:299) > at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1145) > at org.hibernate.ejb.Ejb3Configuration.createEntityManagerFactory(Ejb3Configuration.java:358) > at org.hibernate.ejb.Ejb3Configuration.createEntityManagerFactory(Ejb3Configuration.java:484) > at org.hibernate.ejb.Ejb3Configuration.createContainerEntityManagerFactory(Ejb3Configuration.java:202) > at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:78) > at org.jboss.ejb3.Ejb3Deployment.initializeManagedEntityManagerFactory(Ejb3Deployment.java:512) > at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:253) > at org.jboss.ejb3.Ejb3JmxDeployment.create(Ejb3JmxDeployment.java:230) > at org.jboss.ejb3.Ejb3Module.createService(Ejb3Module.java:34) > at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:245) > at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:228) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141) > at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80) > at org.jboss.mx.server.Invocation.invoke(Invocation.java:72) > at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245) > at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644) > at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:943) > at $Proxy0.create(Unknown Source) > at org.jboss.system.ServiceController.create(ServiceController.java:341) > at org.jboss.system.ServiceController.create(ServiceController.java:284) > at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141) > at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80) > at org.jboss.mx.server.Invocation.invoke(Invocation.java:72) > at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245) > at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644) > at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176) > at $Proxy10.create(Unknown Source) > at org.jboss.ejb3.EJB3Deployer.create(EJB3Deployer.java:208) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141) > at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80) > at org.jboss.mx.server.Invocation.invoke(Invocation.java:72) > at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245) > at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644) > at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176) > at $Proxy11.create(Unknown Source) > at org.jboss.deployment.MainDeployer.create(MainDeployer.java:935) > at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:789) > at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753) > at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141) > at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80) > at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118) > at org.jboss.mx.server.Invocation.invoke(Invocation.java:74) > at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127) > at org.jboss.mx.server.Invocation.invoke(Invocation.java:74) > at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245) > at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644) > at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176) > at $Proxy6.deploy(Unknown Source) > at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:319) > at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:489) > at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:192) > at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:203) > at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:182) > 09:13:51,528 INFO [EJB3Deployer] Deployed: file:/C:/work/jboss-4.0.3SP1/server/default/deploy/bizmerit.ejb3 -- 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

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-511) reattach object from same session

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-511?page=co... ] Steve Ebersole commented on HHH-511: ------------------------------------ Markus, regardless of what you want to do or dont want to do, throwing away the session is the only supported means for exception handling. > reattach object from same session > --------------------------------- > > Key: HHH-511 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-511 > Project: Hibernate3 > Issue Type: Bug > Components: core > Reporter: Gavin King > Priority: Minor > Attachments: reattach-same-session.patch, reattach-same-session.patch > > > http://forum.hibernate.org/viewtopic.php?p=2231400#2231400 > There is a problem when you reattach a collection to the same session that it was previously attached to, after calling clear(). Hibernate checks the collections session reference, at reattach and concludes it is already attached. -- 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

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-511) reattach object from same session

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-511?page=co... ] Steve Ebersole commented on HHH-511: ------------------------------------ Rodrigo, thanks for the patch. Initially I am inclined to think that the correct solution is to simply "unset" the session references for collections and proxies during clear (currently, they are simply removed from the session's persistence context, but their session reference is never cleared). Perhaps a better solution is to basically run evict() on all persistence context entries since evict does all of this work already. Could you include test cases for all the scenarios you saw failing? > reattach object from same session > --------------------------------- > > Key: HHH-511 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-511 > Project: Hibernate3 > Issue Type: Bug > Components: core > Reporter: Gavin King > Priority: Minor > Attachments: reattach-same-session.patch, reattach-same-session.patch > > > http://forum.hibernate.org/viewtopic.php?p=2231400#2231400 > There is a problem when you reattach a collection to the same session that it was previously attached to, after calling clear(). Hibernate checks the collections session reference, at reattach and concludes it is already attached. -- 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

1
0
0 / 0

[Hibernate-JIRA] Resolved: (HHH-1) Optimize Hibernate for the bulk insertion of related entities

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1?page=com.... ] Steve Ebersole resolved HHH-1. ------------------------------ Assignee: Steve Ebersole Resolution: Fixed Fix Version/s: 3.3 3.2.4 trunk / 3.2 > Optimize Hibernate for the bulk insertion of related entities > ------------------------------------------------------------- > > Key: HHH-1 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1 > Project: Hibernate3 > Issue Type: New Feature > Components: core > Environment: Hibernate 1.2, MySql 3.1 > Reporter: Bradley Leupen > Assignee: Steve Ebersole > Priority: Minor > Fix For: 3.2.4, 3.3 > > Attachments: bulk_insert.patch > > > It is currently difficult to batch the creation of persistent entities that maintain associations with other entities. > Add necessary api to hibernate to support the save or update of a collection of entities. An optimization can be applied in this scenario to group inserts / updates by entity class, or table. This will enable the hibernate engine to utilize batching if available, drastically improving performance over a network. -- 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

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-2553) New LoadContexts Implementation causing possible performance degradation

by Shawn Clowater (JIRA)

New LoadContexts Implementation causing possible performance degradation ------------------------------------------------------------------------- Key: HHH-2553 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2553 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.3 Reporter: Shawn Clowater Priority: Critical Noticed that some of our unit tests began to suffer a 300% decrease in performance with the latest 3.2.3 release. Fetches that were taking in the order of 20s were now up around a minute. Stuck a profiler on the test run including the Hibernate classes in the profile and the CollectionLoadContext immediately filtered to the top getting tens of millions of hits in the locateLoadingCollectionEntry chain of methods. Looked at one of the offending tests and it ends up loading ~ 1000 entities and the collectionLoadContexts property of the LoadContexts class peaks at about 9500. I'm thinking the iteration of the contents of the collectionLoadContexts collection is going to cause grief for anyone loading a substantial amount of entities at a given time. I believe the implementation before was there used to be 1 lookup of a Map key to find a collection where now you may end up with n number of key lookups where n is the number of CollectionLoadContexts that you have. (in my case 9500ish) The specific piece of code from LoadContexts I am referring to is: LoadingCollectionEntry locateLoadingCollectionEntry(CollectionKey key, CollectionLoadContext caller) { if ( collectionLoadContexts == null ) { return null; } if ( log.isTraceEnabled() ) { log.trace( "attempting to locate loading collection entry [" + key + "] in any result-set context" ); } LoadingCollectionEntry rtn = null; Iterator itr = collectionLoadContexts.values().iterator(); while ( itr.hasNext() ) { final CollectionLoadContext collectionLoadContext = ( CollectionLoadContext ) itr.next(); if ( collectionLoadContext == caller ) { continue; } rtn = collectionLoadContext.getLocalLoadingCollectionEntry( key ); if ( rtn != null ) { if ( log.isTraceEnabled() ) { log.trace( "collection [" + key + "] located in load context [" + collectionLoadContext + "]" ); } break; } } return rtn; } I'm not quite clear as to the purpose of the underlying change but just wanted to at least let you guys know that it might cause less than optimal performance using the 3.2.2 release as a baseline. -- 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

2
7
0 / 0

[Hibernate-JIRA] Created: (HBX-927) Incorrect syntax on insert statement

by Robert Stone (JIRA)

Incorrect syntax on insert statement ------------------------------------ Key: HBX-927 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-927 Project: Hibernate Tools Issue Type: Bug Environment: Hibernate 3.1.3 Postgres 7.4.7 Tomcat 5.5.12 localhost running on Debian AMD 64 Reporter: Robert Stone All of a sudden, any insert statement constructed by Hibernate has this "select scope_identity()" appended to it that naturally causes a SQLGrammar exception. This occurred one day to the next. There has been NO change to the operating environment. The box accessible by users has exactly the same environment except it is an Intel chipset and it is working as normal. Hibernate: insert into mothers_medical_history (au_vers_numb, date_of_occurrence, icd_code, mmh_comments, record_created_by, datetime_created, mothers_id) values (?, ?, ?, ?, ?, ?, ?) select scope_identity() Can anybody help????? -- 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

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2306) put() fails on lazy one-to-many Map

by Andreas Idl (JIRA)

put() fails on lazy one-to-many Map ----------------------------------- Key: HHH-2306 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2306 Project: Hibernate3 Type: Bug Versions: 3.2.0.ga, 3.2.1 Environment: HIbernate 3.2.1. with Mysql 4 Reporter: Andreas Idl Priority: Critical Attachments: MapTest.zip If I add n objects to a lazy-loaded one-to-many map, the first added object is not contained afterwards. The size of the map is (n-1). Document document = (Document) session.load(Document.class,documentId); DocumentHistory history = new DocumentHistory(); history.setVersion(1); history.setTitle(document.getTitle()); history.setContent(document.getContent()); history.setDocument(document); // Put the new history into the map. Map<Integer, DocumentHistory> histories = document.getHistories(); histories.put(history.getVersion(), history); //not equal because histories.size() is 0 assertEquals(1, histories.size()); -- 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

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2533) redesign Cache/CacheProviders

by Steve Ebersole (JIRA)

redesign Cache/CacheProviders ----------------------------- Key: HHH-2533 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2533 Project: Hibernate3 Issue Type: Improvement Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.3 The main thrust of this work is the splitting of o.h.c.Cache into specializations based on the type of data to be stored (entity data, collection data, etc). -- 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

1
4
0 / 0

[Hibernate-JIRA] Created: (HHH-2554) no precision and scale attributes in <key-property> mapping element

by Maxim Gordienko (JIRA)

no precision and scale attributes in <key-property> mapping element ------------------------------------------------------------------- Key: HHH-2554 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2554 Project: Hibernate3 Issue Type: Improvement Affects Versions: 3.2.3 Reporter: Maxim Gordienko key-property element in hibernate-mapping-3.0.dtd has no precision and scale attributes that affects schema creation/validation. (nevertheless it has length property) -- 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

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2549) Warn users explicitly about schemaexport does not support annotations

by Max Rydahl Andersen (JIRA)

Warn users explicitly about schemaexport does not support annotations --------------------------------------------------------------------- Key: HHH-2549 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2549 Project: Hibernate3 Issue Type: Improvement Components: core Affects Versions: 3.2.3 Reporter: Max Rydahl Andersen Fix For: 3.2.4 Users does not realize hibernate core doesn't do annotation and thus the builtin schemaexport ant task does not help them. Printing something like the following when running could help them in the right direction (since no error might not occur if their cfg.xml is empty) ""This is an Ant task for JDK 1.4, if you want to use annotations, use http://tools.hibernate.org/"" The error message could be improved similarily (see http://forum.hibernate.org/viewtopic.php?t=972724) -- 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

1
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues April 2007