July 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3551) Boolean substitution in informix

by Rouvignac (JIRA)

Boolean substitution in informix -------------------------------- Key: HHH-3551 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3551 Project: Hibernate Core Issue Type: Bug Components: query-sql Affects Versions: 3.3.1 Environment: Hibernate 3.2 Informix 9.40 Reporter: Rouvignac HQL Query : select order from Order order where order.printed = ? Parameter : true, false, Boolean.TRUE or Boolean.FALSE When the request is executed we get the following error : SQLSTATE: IX000 SQL CODE: -674 674: Routine (equal) can not be resolved. If as parameter we use "t" ot "f" everything works fine but it will not work with other DB. As a workaround we can use : property name="hibernate.query.substitutions">true t, false f</property> I investigated in Dialects : Dialect.java public String toBooleanValueString(boolean bool) { return bool ? "1" : "0"; } PostgreSQLDialect.java public String toBooleanValueString(boolean bool) { return bool ? "true" : "false"; } InformixDialect.java uses Dialect.java toBooleanValueString method. In my mind toBooleanValueString should be added to InformixDialect.java as follow : public String toBooleanValueString(boolean bool) { return bool ? "t" : "f"; } -- 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

4
8
0 / 0

[Hibernate-JIRA] Created: (HHH-3984) onPrepareStatement is called twice.

by Tobias Bergman (JIRA)

onPrepareStatement is called twice. ----------------------------------- Key: HHH-3984 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3984 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.5 Environment: Windows, MySQL 5, Java 1.6 Reporter: Tobias Bergman onPrepareStatement is called twice when batched. First getSQL(sql) (which will call the interceptor) is called from prepareBatchStatement. After the invokation the prepareBatchStatement() will call prepareStatement(sql) which will also call getSQL(). -- 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

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-4511) Problems with polymorphic queries with SINGLE_TABLE inheritance strategy

by Karoly Gacsal (JIRA)

Problems with polymorphic queries with SINGLE_TABLE inheritance strategy ------------------------------------------------------------------------ Key: HHH-4511 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4511 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.5.0.Beta-1 Environment: envers 1.2.1 Hibernate 3.3.2 Reporter: Karoly Gacsal Attachments: ChildAuditing.java Inheritance strategy is SINGLE_TABLE (discriminator). When I query for ParentType I do not get ChildType instances in the result, but ParentType instances. I checked the problem against envers 1.2.1/Hibernate 3.3.2 and against Hibernate 3.5.0.Beta-1 too. The testcase "\src\test\java\org\hibernate\envers\test\integration\inheritance\single\ChildAuditing.java" passes, but when I change the two sides of the equals method in testPolymorphicQuery()'s second assert the testcase fails, because the expected result is a ChildEntity, but in the result we get an instance of ParentEntity. Attached you can find the testcases changed by me. -- 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

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-5095) BasicLoader.isBag() checks type assignability wrongly

by Matt Benson (JIRA)

BasicLoader.isBag() checks type assignability wrongly ----------------------------------------------------- Key: HHH-5095 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5095 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.0-Final Environment: N/A Reporter: Matt Benson Method defined as: {code} private boolean isBag(CollectionPersister collectionPersister) { return collectionPersister.getCollectionType().getClass().isAssignableFrom( BagType.class ); } {code} Will never return true if the returned CollectionType subclasses BagType; should IMO be: {code} private boolean isBag(CollectionPersister collectionPersister) { return BagType.class.isInstance( collectionPersister.getCollectionType() ); } {code} My humble apologies for the submission without a test case, but this one feels pretty simple. Thanks! -- 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

2
10
0 / 0

[Hibernate-JIRA] Created: (HHH-5236) Exception with hibernate model

by Michael Zhang (JIRA)

Exception with hibernate model ------------------------------ Key: HHH-5236 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5236 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.2, 3.5.0-Final, 3.2.0.ga Environment: Java 1.5 Windows/Unix Reporter: Michael Zhang I have a hibernate model class member e.g. (active) that is mapped to a string (either "Y" or "N"). Both getter and setter are implemented. There is also another method in the class: public boolean isActive()... When test it from JUnit, everything works fine. However when the class is accessed from thread with database update operation, hibernate will throw ClassCast exception from Boolean to String. If the method of "isActive" is changed to something else such as "isActiveMethod", the exception will disappeare. -- 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

2
4
0 / 0

[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

14 years

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

14 years

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

14 years

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

14 years

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-5405) many-to-one id="true" is not picked up by hibernate in orm.xml

by Rolf Thunbo (JIRA)

many-to-one id="true" is not picked up by hibernate in orm.xml -------------------------------------------------------------- Key: HHH-5405 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5405 Project: Hibernate Core Issue Type: Bug Components: metamodel Affects Versions: 3.5.2 Reporter: Rolf Thunbo When making a composite key referring to a target entity something like the following ORM XML should be defined: <?xml version="1.0" encoding="UTF-8"?> <entity-mappings xmlns="http://java.sun.com/xml/ns/persistence/orm" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm http://java.sun.com/xml/ns/persistence/orm_2_0.xsd" version="2.0"> <entity class="Subscription"> <table name="SUBSCRIPTION"/> <id-class class="SubscriptionKey"/> <attributes> ... <many-to-one name="owner" id="true"> <join-column name="FK_SUBSCRIBER_CVR"/> </many-to-one> </attributes> </entity> </entity-mappings> But for some reason the id attribute is not picked up by Hibernate, and therefore it does not interpret the relation as a primary key. A workaround is to add a id tag referring to the same property, but it would be nice of Hibernate would pick up the id attribute on the many-to-one relation. -- 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

2
1
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues July 2010