October 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3524) setFetchMode ignored if using createCriteria

by Peter Weemeeuw (JIRA)

setFetchMode ignored if using createCriteria -------------------------------------------- Key: HHH-3524 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3524 Project: Hibernate Core Issue Type: Bug Components: query-criteria Affects Versions: 3.2.5 Environment: Hibernate 3.2.5, Oracle 8 Reporter: Peter Weemeeuw Hi, It seems that criteria.setFetchMode gets ignored if you combine it with createCriteria to add a restriction. This works as expected: DetachedCriteria c = DetachedCriteria.forClass(MenuItem.class); c.setFetchMode("menuItemSubscriptions", FetchMode.JOIN); But in this case the join doesn't happen (and I get a LazyInstantiationException further on). DetachedCriteria c = DetachedCriteria.forClass(MenuItem.class); c.setFetchMode("menuItemSubscriptions", FetchMode.JOIN); c.createCriteria("menuItemSubscriptions").add( Restrictions.eq("location", "B") ); This does not happen if I set lazy="false" in the mappings file. Regards, Peter -- 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

13 years, 10 months

8
13
0 / 0

[Hibernate-JIRA] Created: (ANN-747) @CollectionOfElements does not cascade on delete

by Nicole Rauch (JIRA)

@CollectionOfElements does not cascade on delete ------------------------------------------------ Key: ANN-747 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-747 Project: Hibernate Annotations Issue Type: Bug Affects Versions: 3.3.1.GA Environment: Hibernate 3.2.6 GA Database: H2 1.0.72 Reporter: Nicole Rauch Consider the following constellation: @Embeddable public class Foo { // ... } @Entity public class Bar { @CollectionOfElements private Set<Foo> myFoos; // ... } When I persist a Bar object that contains some Foos, and when I later decide to delete the Bar object, I get a foreign key constraint violation error message because the Foo objects, which contain a reference to the Bar object that owns them, are not deleted automatically. I would expect the default behaviour to be "on delete cascade" because the Foo objects are embeddables, thus they cannot exist on their own without the Bar object that owns them. But there is no way to tell Hibernate to cascade: - the @OnDelete annotation is only allowed for OneToMany relations - the @Cascade annotation is being ignored - there is no "cascade" property for the CollectionOfElements So my question is: Why does the cascading not occur automatically, and how do I tell Hibernate to cascade anyways? Thanks a lot in advance, Nicole -- 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

13 years, 10 months

4
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3273) One-to-Many relationship not working with custom Loader

by Darren Hicks (JIRA)

One-to-Many relationship not working with custom Loader -------------------------------------------------------- Key: HHH-3273 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3273 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.6, 3.2.5, 3.2.4, 3.2.3, 3.2.2, 3.2.1 Environment: hibernate-3.2.6.jar Reporter: Darren Hicks Within the context of a One-to-Many relationship, NamedQueryCollectionInitializer .initialize() never actually populates the PersistantBag on the parent after it calls query.setCollectionKey( key ).setFlushMode( FlushMode.MANUAL ).list() to retrieve the children. This is documented in the forums here: http://forums.hibernate.org/viewtopic.php?t=986428 Additionally, the poster has a fix posted which may solve the problem, or at least lay out the groundwork for a solution. Here is the proposed implementation of NamedQueryCollectionInitializer.initialize(): public void initialize(Serializable key, SessionImplementor session) throws HibernateException { if (log.isDebugEnabled()) { log.debug("initializing collection: " + persister.getRole() + " using named query: " + queryName); } // TODO: is there a more elegant way than downcasting? AbstractQueryImpl query = (AbstractQueryImpl) session .getNamedSQLQuery(queryName); if (query.getNamedParameters().length > 0) { query.setParameter(query.getNamedParameters()[0], key, persister .getKeyType()); } else { query.setParameter(0, key, persister.getKeyType()); } List list = query.setCollectionKey(key).setFlushMode(FlushMode.MANUAL) .list(); // Uh, how 'bout we save the collection for later retrieval? CollectionKey collectionKey = new CollectionKey(persister, key, session .getEntityMode()); for (Object object : session.getPersistenceContext() .getCollectionsByKey().keySet()) { if (collectionKey.equals(object)) { PersistentCollection persistentCollection = session .getPersistenceContext().getCollection(collectionKey); Serializable[] serializables = new Serializable[list.size()]; for (int i = 0; i < list.size(); i++) { serializables[i] = persister.getElementType().disassemble( list.get(i), session, persistentCollection.getOwner()); } persistentCollection.initializeFromCache(persister, serializables, persistentCollection.getOwner()); persistentCollection.setSnapshot(key, persistentCollection .getRole(), serializables); persistentCollection.afterInitialize(); session.getPersistenceContext().getCollectionEntry( persistentCollection).postInitialize( persistentCollection); } } } -- 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

13 years, 10 months

6
9
0 / 0

[Hibernate-JIRA] Created: (EJB-328) Missing flush before lock() when LockModeType is AUTO

by Per Olesen (JIRA)

Missing flush before lock() when LockModeType is AUTO ----------------------------------------------------- Key: EJB-328 URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-328 Project: Hibernate Entity Manager Issue Type: Bug Components: EntityManager Affects Versions: 3.3.1.GA Environment: core: 3.2.5.ga entitymanager: 3.3.1.ga annotations: 3.3.0.ga Reporter: Per Olesen Priority: Minor When I try to WRITE lock() a newly persisted entity using entityManager.lock, I get a StaleObjectStateException, telling me that some other transaction updated or deleted the row. I am doing this in the same transaction (persist and lock). By digging into the code, I see that the exception is thrown inside the SelectLockingStrategy.lock method, around these lines: ResultSet rs = st.executeQuery(); try { if ( !rs.next() ) { if ( factory.getStatistics().isStatisticsEnabled() ) { factory.getStatisticsImplementor() .optimisticFailure( lockable.getEntityName() ); } throw new StaleObjectStateException( lockable.getEntityName(), id ); } } The query executed here is the one which performs the select on id with FOR UPDATE. This select finds nothing, hence the exception. Setting show_sql = true shows me, that no insert is performed. Debugging the flush mode tells me, that it is set to AUTO. Shouldn't AUTO flush mode have the side effect, that a flush is performed before a query? Performing an explicit flush, before the lock, makes everything green :-), so this is my current work-around. Here is the exception (sanitized for company info): org.springframework.orm.jpa.JpaOptimisticLockingFailureException: nested exception is javax.persistence.OptimisticLockException Caused by: javax.persistence.OptimisticLockException at org.hibernate.ejb.AbstractEntityManagerImpl.wrapStaleStateException(AbstractEntityManagerImpl.java:643) at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:600) at org.hibernate.ejb.AbstractEntityManagerImpl.lock(AbstractEntityManagerImpl.java:379) ... Caused by: org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [com.foo.bar#32] at org.hibernate.dialect.lock.SelectLockingStrategy.lock(SelectLockingStrategy.java:78) at org.hibernate.persister.entity.AbstractEntityPersister.lock(AbstractEntityPersister.java:1334) at org.hibernate.event.def.AbstractLockUpgradeEventListener.upgradeLock(AbstractLockUpgradeEventListener.java:88) at org.hibernate.event.def.DefaultLockEventListener.onLock(DefaultLockEventListener.java:64) at org.hibernate.impl.SessionImpl.fireLock(SessionImpl.java:584) at org.hibernate.impl.SessionImpl.lock(SessionImpl.java:576) at org.hibernate.ejb.AbstractEntityManagerImpl.lock(AbstractEntityManagerImpl.java:376) ... -- 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

13 years, 10 months

2
2
0 / 0

[Hibernate-JIRA] Created: (ANN-848) Bidirectional Polymorphism

by Yong Joo Jeong (JIRA)

Bidirectional Polymorphism -------------------------- Key: ANN-848 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-848 Project: Hibernate Annotations Issue Type: New Feature Components: binder Affects Versions: 3.4.0.GA Environment: 3.4.0.GA, Any database Reporter: Yong Joo Jeong I'm trying to implement bidirectional polymorphic class. Code: public class Order{ ... @Any( metaColumn = @Column( name = "item_type" ), fetch=FetchType.EAGER ) @AnyMetaDef( idType = "long", metaType = "string", metaValues = { @MetaValue( value = "ItemA", targetEntity = ItemA.class ), @MetaValue( value = "ItemB", targetEntity = ItemB.class ) } ) @JoinColumn( name = "item_id" ) Object item; ... } And trying to do somthing like the following Code: public class ItemA { @OneToAny // like @OneToMany; in Order table there are "item_id" and "item_type" fields to distinguish ItemA and ItemB List<Order> orders; ... } RoR support this kind of relationship, but I can't find it from Hibernate. Inheritance with "Table per class" is not an option since it does not support the IDENTITY generator strategy. Any solution for this? -- 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

13 years, 10 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HBX-1092) hbm2doc with graphing fails on MacOSX

by Avram Cherry (JIRA)

hbm2doc with graphing fails on MacOSX ------------------------------------- Key: HBX-1092 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1092 Project: Hibernate Tools Issue Type: Bug Components: hbm2doc Affects Versions: 3.2.0.GA, 3.2.2 Reporter: Avram Cherry In the method org.hibernate.tool.hbm2x.DocExporter.dotToFile, the portions of the command passed to Runtime.exec() are being passed to an escape(String) method that optionally adds quotes to the executable file path and the path to the input file, but only if the OS is not linux. MacOSX is not linux, but adding quotes causes exec() to fail. The solution is to change the following statement: String exeCmd = escape(dotExeFileName) + " -T" + getFormatForFile(outFileName) + " " + escape(dotFileName) + " -o " + escape(outFileName); to: String[] exeCmd = new String[] {dotExeFileName, " -T", getFormatForFile(outFileName), dotFileName, " -o ", outFileName}; If you pass the command and arguments as separate strings within an array to Runtime.exec() you do not need to quote filenames, regardless of platform. A (potentially very harmful) workaround is to pass -Dos.name=Linux to the VM. Please note that I've checked both the 3.2 branch and trunk and both contain the same 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

13 years, 10 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3824) OneToOne join by Non-primary key column throws PropertyAccessException when join column is String

by sathish (JIRA)

OneToOne join by Non-primary key column throws PropertyAccessException when join column is String ------------------------------------------------------------------------------------------------- Key: HHH-3824 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3824 Project: Hibernate Core Issue Type: Bug Components: query-criteria, query-hql Affects Versions: 3.3.1 Environment: Microsoft SQL server 2005, Hibernate 3.3.1 Reporter: sathish Attachments: trace.txt When i try to join 2 entities by OneToOne using a Non-primary key column, it throws the following exception: org.hibernate.PropertyAccessException: could not get a field value by reflection getter of com.xxx.domain.Inventory.sku Caused by: java.lang.IllegalArgumentException: Can not set java.lang.String field com.inwk.estore.server.domain.Inventory.sku to java.lang.Integer [Full stacktrace attached] sku is the Non-primary key String join column by which im trying to do a OneToOne join between Item and Inventory entity. Apparently its trying to interpret Sku as an Integer column. Adding columnDefinition as VARCHAR/String doesn't help either Mappings for Item and Inventory are below: class Item{ @Id Long id; @Column String sku; //some more properties @OneToOne(optional = true) @JoinColumn(name = "sku", referencedColumnName = "sku", insertable = false, updatable = false) Inventory inventory; } class Inventory{ @Id Long id @Column String sku @Column Long quantity; } -- 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

13 years, 10 months

9
14
0 / 0

[Hibernate-JIRA] Created: (HHH-3659) statistics: Execution time of a query

by Anthony Patricio (JIRA)

statistics: Execution time of a query ------------------------------------- Key: HHH-3659 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3659 Project: Hibernate Core Issue Type: New Feature Components: query-hql, query-sql Affects Versions: 3.3.1 Reporter: Anthony Patricio Priority: Trivial Currently we have min, average and max execution time. Could be useful to log each query execution time. -- 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

13 years, 11 months

4
6
0 / 0

[Hibernate-JIRA] Created: (HHH-3007) Unchanged persistent set gets marked dirty on session.merge()

by Lars Koedderitzsch (JIRA)

Unchanged persistent set gets marked dirty on session.merge() ------------------------------------------------------------- Key: HHH-3007 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3007 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5 Reporter: Lars Koedderitzsch Persistent sets are marked dirty on session.merge() even if there have been no changes to the collection. This is especially painful when the collection is immutable and results in an "changed an immutable collection instance" exception on flush. I tracked the behaviour down a bit and believe the problem to be in CollectionType.replace(). Here the passed in orginal PersistentSet is replaced by a plain HashSet in this line: Object result = target == null || target == original ? instantiateResult( original ) : target; The "result" object (HashSet) is then passed to the CollectionType.replaceElements() method (instead of the original PersistentSet). In CollectionType.replaceElements() the code to clear the dirty state of the collection does not execute anymore, because the passed-in "original" collection is the described HashSet and *not* the original PersistentSet. This way the PersistentSet remains marked dirty. A workaround is to manually clear the dirty state of an immutable collection after merge but before flush. -- 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

13 years, 11 months

3
8
0 / 0

[Hibernate-JIRA] Created: (HHH-4539) Make UPPER and LOWER work on MS SQL Server text and ntext columns

by Sergiu Dumitriu (JIRA)

Make UPPER and LOWER work on MS SQL Server text and ntext columns ----------------------------------------------------------------- Key: HHH-4539 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4539 Project: Hibernate Core Issue Type: Improvement Components: query-sql Affects Versions: 3.3.2 Environment: MS SQL Server Reporter: Sergiu Dumitriu Trying to use UPPER or LOWER on a text column results in: ERROR util.JDBCExceptionReporter - Argument data type text is invalid for argument 1 of upper function. http://databases.aspfaq.com/database/why-do-i-get-argument-data-type-text... suggests a workaround, which I think should be automatically used by Hibernate, so that the HQL query can work with other dialects. -- 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

13 years, 11 months

3
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues October 2009