August 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3560) Assume entities relationships as unversioned by default

by Adam Warski (JIRA)

Assume entities relationships as unversioned by default ------------------------------------------------------- Key: HHH-3560 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3560 Project: Hibernate Core Issue Type: New Feature Components: envers Reporter: Adam Warski http://www.jboss.com/index.html?module=bb&op=viewtopic&t=141471 Assume that each relation between entities is unversioned unless entity is explicitly annotated with @Versioned. In current implementation if versioned entity has reference to non-versioned entity an MappingException is being thrown unless the @Unversioned annotation is used in appropriate field. If there is a lot of entities that are referenced but not versioned it requires to apply lot of @Unversioned annotations. This is quite error-prone while it is easy to forgot about some fields. I've suggest to treat each reference to entity as it is annotated with @Unversioned unless the entity is annotated with @Versioned. In other words treat entities ralationships as implicitly @Unversioned unless @Versioned is not set explicitly. -- 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

16 years, 1 month

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4010) support auditing of entity having reference (many-to-one relation) to not audited entity

by Tomasz Bech (JIRA)

support auditing of entity having reference (many-to-one relation) to not audited entity ---------------------------------------------------------------------------------------- Key: HHH-4010 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4010 Project: Hibernate Core Issue Type: New Feature Components: envers Affects Versions: 3.3.2 Reporter: Tomasz Bech There is an annotated (with @Audited) entity class (lets say - class A), it has ManyToOne reference to another class (lets named this class as B). For various reason, class B should stay as not audited - for example because B is a static dictionary class with milion of records, so duplications in the Audited table is not advised or possible. Currently this is not supported by evners (target entity must me audited as well for now). Related topic on forum: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157846 We are going to implement this feature and provide the patch as well. -- 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

16 years, 1 month

2
3
0 / 0

[Hibernate-JIRA] Created: (HV-186) ResourceBundleMessageInterpolator has to allow all characters as message parameter

by Hardy Ferentschik (JIRA)

ResourceBundleMessageInterpolator has to allow all characters as message parameter ---------------------------------------------------------------------------------- Key: HV-186 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-186 Project: Hibernate Validator Issue Type: Bug Affects Versions: 4.0.0.Beta2 Reporter: Hardy Ferentschik Fix For: 4.0.0.GA At the moment only word characters and '.' are allowed. This excludes for example '-'. However, does it really make sense to allow any character? -- 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

16 years, 1 month

1
5
0 / 0

[Hibernate-JIRA] Created: (HHH-2830) Insert error ignored when using sybase generated identity column

by Martin van Dijken (JIRA)

Insert error ignored when using sybase generated identity column ---------------------------------------------------------------- Key: HHH-2830 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2830 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.2 Environment: Hibernate 3.2.2, Sybase 12.5.3 Reporter: Martin van Dijken All our tables have a single database generated identity column. This column is specified in Sybase as: objectId numeric(12) identity A little while ago, Hibernate started throwing NonUniqueObjectExceptions upon insert of a certain object. It turns out, the insert statement could not possibly succeed as the value of one of the columns was larger than the database column. The error is however ignored because Hibernate generates a query: insert into objectTable (objectName, objectNumericErrorField) values (?,?) select @@ identity The value of objectNumericErrorField was larger than the database column allows. The insert statement would therefore fail. The select @@identity however would succeed, only because no new row was inserted it would return the previous ID. Hibernate then assumes the entire query worked fine and would assign the already assigned id to a different object. It would then check whether or not the id was already in use and throw a NonUniqueObjectException -- 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

16 years, 1 month

5
6
0 / 0

[Hibernate-JIRA] Created: (HV-197) Implement a LazyValidatorFactory

by Emmanuel Bernard (JIRA)

Implement a LazyValidatorFactory -------------------------------- Key: HV-197 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-197 Project: Hibernate Validator Issue Type: New Feature Affects Versions: 4.0.0.Beta2 Reporter: Emmanuel Bernard Assignee: Emmanuel Bernard Fix For: 4.0.0.CR1 -- 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

16 years, 1 month

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4071) Need for a new -to-many fetch mode, retrieving children ids only (otherwise L2 cache is poorly used when retrieving collections of cached objects)

by Yannick le Restif (JIRA)

Need for a new -to-many fetch mode, retrieving children ids only (otherwise L2 cache is poorly used when retrieving collections of cached objects) -------------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-4071 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4071 Project: Hibernate Core Issue Type: Improvement Components: caching (L2) Affects Versions: 3.3.0.SP1 Environment: hibernate : 3.3.0 database : probably not pertinent (sybase 12.5) Reporter: Yannick le Restif The proposed improvement is a -to-many association fetch mode (maybe lazy mode) where only children ids would be fetched when we fetch the collection, rather than whole children entities, as it is the case now. Suppose we use a second level cache for children entities, and that we warm this cache up at application start : We will still fetch these children entites each time we fetch a collection of such entities, althought all of them were available in the second level cache ! Of course using a collections cache helps a bit, but only a bit, because of course we will then fetch a *given* collection only once, but that could still mean a lot of unnecessary entity fetching if one entity is in many collections. With the new fetch mode proposed, we would only fetch the children ids list, and then get the entities one by one lazily, allowing for using the cache, so the only SQL generated would for example be if we are fetching Bids for an Item : SELECT bids.id FROM bids WHERE bids.item_id = 123 instead of SELECT bids.id, bids.user, bids.date, ... FROM bids WHERE bids.item_id = 123 If the collection itself is cached, the result can be cached as the collection value (L2 collections cache only contains collections of ids, if I'm not mistaking...?) The mode could then also be used warm collections caches up. Maybe there is a way to get around this, but I found neither that was satisfactory. The "best" I found is to link the father entity to a collection of "id entities", themselves linked (one-to-one) to the "real", big entity. But this is not handy. -- 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

16 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-2656) Using EntityMode.DOM4J results in an exception when mapping more than one collection to the root node (node=".")

by Andries Schutte (JIRA)

Using EntityMode.DOM4J results in an exception when mapping more than one collection to the root node (node=".") ---------------------------------------------------------------------------------------------------------------- Key: HHH-2656 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2656 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.4.sp1 Environment: Hibernate 3.2.4 SP1, tested with MySQL 5.0. Reporter: Andries Schutte When mapping multiple collections to the root node, an exception results (mapping and exception stack trace is shown below). This works fine if only one collection is mapped to the root node, or if one explicitly specifies unique names for each collection parent node. We are unfortunately restricted by having to use customer-defined XSDs, so this is a show-stopper for us. <?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"> <hibernate-mapping> <class entity-name="ProcessImpl" table="PROCESSES" node="Process"> <id name="sysID" column="PROCESS_ID" node="sysID" type="string"/> <property name="version" column="PROCESS_VERSION" node="version" type="string"/> <property name="processType" column="PROCESS_TYPE" node="processType" type="string"/> <property name="status" column="PROCESS_STATE" node="status" type="string"/> <property name="createDate" column="PROCESS_CREATE_DATE" node="createDate" type="timestamp"/> <property name="creator" column="PROCESS_CREATOR" node="creator" type="string"/> <property name="transactionNumber" column="PROCESS_TX_NUMBER" node="transactionNumber" type="long"/> <property name="modifiedDate" column="PROCESS_MOD_DATE" node="modifiedDate" type="timestamp"/> <property name="modifier" column="PROCESS_MODIFIER" node="modifier" type="string"/> <property name="title" column="PROCESS_TITLE" node="title" type="string"/> <property name="timer" column="PROCESS_TIMER" node="timer" type="string"/> <property name="currentCSTime" column="PROCESS_CS_TIME" node="currentCSTime" type="timestamp"/> <bag name="requiredActivities" table="REQ_ACTIVITIES" node = "." embed-xml="true" lazy="false" cascade="all"> <key column="PROCESS_ID" not-null="true"/> <element column="REQ_ACTIVITY" type="text" node="requiredActivity"/> </bag> <bag name="retractedGuidelines" table="RET_GUIDELINES" node = "." embed-xml="true" lazy="false" cascade="all"> <key column="PROCESS_ID" not-null="true"/> <element column="RET_GUIDELINE" type="text" node="retractedGuideline"/> </bag> <set name="suspendedGuidelines" node = "." embed-xml="true" lazy="false" cascade="all"> <key column="PROCESS_ID" not-null="true"/> <one-to-many entity-name="SuspendedGuidelineImpl" embed-xml="true" node="suspendedGuideline"/> </set> </class> </hibernate-mapping> Exception stack trace: [6/6/07 22:11:41:246 GMT] 00000012 SystemErr R org.hibernate.HibernateException: Found shared references to a collection: ProcessImpl.retractedGuidelines at org.hibernate.engine.Collections.processReachableCollection(Collections.java:163) at org.hibernate.event.def.FlushVisitor.processCollection(FlushVisitor.java:37) at org.hibernate.event.def.AbstractVisitor.processValue(AbstractVisitor.java:101) at org.hibernate.event.def.AbstractVisitor.processValue(AbstractVisitor.java:61) at org.hibernate.event.def.AbstractVisitor.processEntityPropertyValues(AbstractVisitor.java:55) at org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:131) at org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:196) at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:76) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:26) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000) at com.resonant.persistence.ExternalDataMgrHibernateDom4jImpl.persistHibernateEntity(ExternalDataMgrHibernateDom4jImpl.java:194) at com.resonant.persistence.ExternalDataMgrHibernateDom4jImpl.store(ExternalDataMgrHibernateDom4jImpl.java:172) at com.resonant.persistence.PersistenceHibernateDom4jImpl.storeObject(PersistenceHibernateDom4jImpl.java:215) at com.resonant.persistence.ejb.PersistenceLocalBean.storeObject(PersistenceLocalBean.java:192) at com.resonant.persistence.ejb.EJSLocalStatelessPersistenceLocalEJB_68e55914.storeObject(EJSLocalStatelessPersistenceLocalEJB_68e55914.java:1179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.springframework.ejb.access.LocalSlsbInvokerInterceptor.invoke(LocalSlsbInvokerInterceptor.java:65) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy2.storeObject(Unknown Source) at com.resonant.hub.processmanager.ProcessHubImpl.startProcess(ProcessHubImpl.java:179) at com.resonant.hub.processmanager.ejb.ProcessHubBean.startProcess(ProcessHubBean.java:138) at com.resonant.hub.processmanager.ejb.EJSRemoteStatelessProcessHubEJB_f45832db.startProcess(EJSRemoteStatelessProcessHubEJB_f45832db.java:208) at com.resonant.hub.processmanager.ejb._EJSRemoteStatelessProcessHubEJB_f45832db_Tie.startProcess(_EJSRemoteStatelessProcessHubEJB_f45832db_Tie.java:261) at com.resonant.hub.processmanager.ejb._EJSRemoteStatelessProcessHubEJB_f45832db_Tie._invoke(_EJSRemoteStatelessProcessHubEJB_f45832db_Tie.java:122) at com.ibm.CORBA.iiop.ServerDelegate.dispatchInvokeHandler(ServerDelegate.java:613) at com.ibm.CORBA.iiop.ServerDelegate.dispatch(ServerDelegate.java:466) at com.ibm.rmi.iiop.ORB.process(ORB.java:503) at com.ibm.CORBA.iiop.ORB.process(ORB.java:1552) at com.ibm.rmi.iiop.Connection.respondTo(Connection.java:2673) at com.ibm.rmi.iiop.Connection.doWork(Connection.java:2551) at com.ibm.rmi.iiop.WorkUnitImpl.doWork(WorkUnitImpl.java:62) at com.ibm.ejs.oa.pool.PooledThread.run(ThreadPool.java:95) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1510) -- 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

16 years, 1 month

2
2
0 / 0

[Hibernate-JIRA] Commented: (HHH-772) null in maps are handled inconsistently

by Richard Dingwall (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-772?page=co... ] Richard Dingwall commented on HHH-772: -------------------------------------- I also have a use case that requires this behaviour. Java supports it, the database supports it, why can't Hibernate or NHibernate support it? Otherwise at least an exception should be thrown alerting the caller that it cannot be persisted (as would occur in other situations). > null in maps are handled inconsistently > --------------------------------------- > > Key: HHH-772 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-772 > Project: Hibernate Core > Issue Type: Improvement > Components: core > Reporter: Max Rydahl Andersen > Fix For: 3.1 beta 1 > > > regarding case 00004729. > group.getUsers().put("something", null); > Does not result in any insert. > Inserting "something", null manually into the underlying table and > when hibernate reads the map will have "something"->null in the map. -- 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

16 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-4069) DetachedCriteria with Projections generates invalid SQL when using inheritance with PostgreSQL

by Gajo Csaba (JIRA)

DetachedCriteria with Projections generates invalid SQL when using inheritance with PostgreSQL ---------------------------------------------------------------------------------------------- Key: HHH-4069 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4069 Project: Hibernate Core Issue Type: Bug Components: query-criteria Affects Versions: 3.2.6 Environment: Hibernate 3.2.6 GA with annotations, PostgreSQL 8.3, Ubuntu Linux Reporter: Gajo Csaba Attachments: postgretest.zip PostgreSQL doesn't allow using aliases in the WHERE clause. For example, the following query is invalid: SELECT it.id_item as aaa FROM Item it WHERE aaa=1 The correct query would be: SELECT it.id_item as aaa FROM Item it WHERE it.id_item=1 When having inheritance with a TABLE_PER_CLASS strategy, the HSQL query "select idItem from Item where idItem=:idItem" will generate the correct query. However, doing the same with a DetachedCriteria will generate the invalid query. Note that I'm not selecting everything from Item. It's not select *. I'm only selecting idItem, which means in the DetachedCriteria I'm using Projections. Without projections, the generated query works fine. I've attached a test case, and the following is a short explanation: model.Item - abstract superclass model.Product - extends Item model.Project - extends Item Main is the main class. Removing the following piece of code will make the test case work without errors: criteria.setProjection(Projections.projectionList() .add(Projections.property("idItem"), "idItem") .add(Projections.property("name"), "name")); The test case may be compiled with Maven. -- 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

16 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-4067) query cache always returns result with lazy collections even the query eager fetch the collection

by shaoxian yang (JIRA)

query cache always returns result with lazy collections even the query eager fetch the collection ------------------------------------------------------------------------------------------------- Key: HHH-4067 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4067 Project: Hibernate Core Issue Type: Bug Components: caching (L2), query-criteria Affects Versions: 3.3.2 Environment: hibernate 3.3.2 ehcache 1.6.0 Reporter: shaoxian yang I am trying to give second level cache and query cache a try for my project. here is the versio information: 1. Hibernate: 3.3.2 2. EHCache: 1.6.0 However, although query cache seems to be working. It always return result with lazy collections, even if my original query eagerly fetch the collections. For example: In Service class // open session criteria = session.createCriteria(Podcast.class); criteria.setFirstResult(offset); org.hibernate.Criteria criteria = session.createCriteria(Podcast.class); criteria.setFetchMode("podcastCategoryMappings", FetchMode.JOIN); criteria.add(Restrictions.in("id", podIds)); criteria.setResultTransformer(CriteriaSpecification.DISTINCT_ROOT_ENTITY); criteria.addOrder(Order.asc("title")); criteria.setCacheable(true); // turn on cache podcasts = criteria.list(); // close session In client class, I expect getting a podcast class, with podcastCategoryMappings collection fetched. @Test public void testGetAllPodcasts() { // first time, it goes through database, and put into cache the query result (id=1), entity (podcast), collections(podcastCategoryMapppings) List<Podcast> podcasts = _service.getPodcasts(0, 1); for (Podcast pod: podcasts) { Set<PodcastCategoryMapping> mappings = pod.getPodcastCategoryMappings(); for (PodcastCategoryMapping mapping: mappings) { System.out.println("pod title/id: " + pod.getTitle() + "/" + pod.getId() + " category id: " + mapping.getCategoryId()); } // second time, the results come from cache. I shall expect cache hit for query result, entity(podcast), and collections. // However, i only see cache hit for query result and entity, not the collections. podcasts = _service.getPodcasts(0, 1); // It will fail with LazyInitializationException since collection is not fully initialized when result returned from cache for (Podcast pod: podcasts) { System.out.println("pod id: " + pod.getId()); Set<PodcastCategoryMapping> mappings = pod.getPodcastCategoryMappings(); for (PodcastCategoryMapping mapping: mappings) { System.out.println("pod title/id: " + pod.getTitle() + "/" + pod.getId() + " category id: " + mapping.getCategoryId()); } } } I turned on the debug message for hibernate cache related classes, so that I know what is wrong with cache. log4j.logger.org.hibernate.cache.ReadWriteCache=TRACE log4j.logger.org.hibernate.cache.UpdateTimestampsCache=TRACE log4j.logger.org.hibernate.cache.StandardQueryCache=TRACE Can someone from hibernate team take a look at this and confirm if this is a bug? I am very close to place this into a project. If this is not working, I guess, I have to manage cache myself, rather than using hibernate to manage the cache. The bottom line is that cache should not return inconsistent result like this. Thanks. Feel free to let me know any more information is needed for 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

16 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues August 2009