May 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-6728) SQLServer2005Dialect - Paging doesn't work with UPPERCASE colums in a case sensitive database

by Andrei Zaitsev (JIRA)

SQLServer2005Dialect - Paging doesn't work with UPPERCASE colums in a case sensitive database --------------------------------------------------------------------------------------------- Key: HHH-6728 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6728 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 4.0.0.CR4, 3.6.7 Environment: MS SQL Server 2008 with Latin1_General_CS_AS collation Reporter: Andrei Zaitsev SQLServer2005Dialect changes the original query in getLimitString() to lowercase. That leads to SQLGrammarExcepton with case sensitive collation and not-lowercase table and column names. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

4
5
0 / 0

[Hibernate-JIRA] Created: (HHH-7198) SQLServer2005Dialect.getLimitString turns tablenames to lowercase -> SQLGrammarException: when mapping tables with capital letters

by Guenther Demetz (JIRA)

SQLServer2005Dialect.getLimitString turns tablenames to lowercase -> SQLGrammarException: when mapping tables with capital letters ----------------------------------------------------------------------------------------------------------------------------------- Key: HHH-7198 URL: https://hibernate.onjira.com/browse/HHH-7198 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 4.1.1 Environment: Hibernate4, SQLServer2008 Reporter: Guenther Demetz Priority: Minor Usually when annotating entity classes without the @Table.name attribute, then the default mapped tablenames begin with a capital letter. When using the paging feature, SQLServer2005Dialect.getLimitString turns the whole sql to lowercase {code:title=SQLServer2005Dialect.java|borderStyle=solid} @Override public String getLimitString(String querySqlString, boolean hasOffset) { StringBuilder sb = new StringBuilder(querySqlString.trim().toLowerCase()); ... return sb.toString(); } {code} thus also the included tablenames are all converted to lowercase, this leads to following schema mismatch exception, when using the original SQLServerDriver: org.hibernate.exception.SQLGrammarException: Invalid object name 'mytable' This bug was introduced with HHH-2655 (ROW_NUMBER for Paging). Testcase: {code} Query query = session.createQuery("from C"); // C is an arbitrary entity class mapped to a table with uppercase characters in the tablename query.setMaxResults(10); query.iterate().next(); // -> Exception {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

4
12
0 / 0

[Hibernate-JIRA] Created: (HHH-7313) DiscriminatorFormulaTest in Hibernate envers Testsuite fails on Sybase(15.7)

by Madhumita Sadhukhan (JIRA)

DiscriminatorFormulaTest in Hibernate envers Testsuite fails on Sybase(15.7) ---------------------------------------------------------------------------- Key: HHH-7313 URL: https://hibernate.onjira.com/browse/HHH-7313 Project: Hibernate ORM Issue Type: Bug Components: envers Affects Versions: 4.1.3 Environment: Sybase 15.7 Reporter: Madhumita Sadhukhan Assignee: Lukasz Antoniak Please refer https://issues.jboss.org/browse/JBPAPP-8964 for details -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

2
8
0 / 0

[Hibernate-JIRA] Created: (HHH-7318) Hibernate incorrecly registers BIGINT as corresponding to Java's BigInteger type.

by Pedro Alvarado (JIRA)

Hibernate incorrecly registers BIGINT as corresponding to Java's BigInteger type. --------------------------------------------------------------------------------- Key: HHH-7318 URL: https://hibernate.onjira.com/browse/HHH-7318 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 4.1.3 Environment: All hibernate versions, all environments. Reporter: Pedro Alvarado The JDBC type BIGINT, per the JDBC specification, corresponds to the Java type long. However, in dialect.java, BIGINT is registered as shown below. Most, if not all databases, use 64 bit integers for BIGINT. Currently: registerHibernateType( Types.BIGINT, StandardBasicTypes.BIG_INTEGER.getName() ); Expected: registerHibernateType( Types.BIGINT, StandardBasicTypes.LONG.getName() ); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-7317) Boolean values bound to parameters in SQL predicate cause failures using DB2 with deferPrepares = true

by Gail Badner (JIRA)

Boolean values bound to parameters in SQL predicate cause failures using DB2 with deferPrepares = true ------------------------------------------------------------------------------------------------------ Key: HHH-7317 URL: https://hibernate.onjira.com/browse/HHH-7317 Project: Hibernate ORM Issue Type: Bug Components: core Reporter: Gail Badner Assignee: Gail Badner Fix For: 4.1.4 This is reproduced by org.hibernate.test.annotations.manytomany.ManyToManyMaxFetchDepth0Test.testCompositePk using DB2 for query: select man0_.elder as elder783_0_, man0_.firstName as firstName783_0_, man0_.lastName as lastName783_0_, man0_.carName as carName783_0_ from Man man0_ where man0_.elder=? and man0_.firstName=? and man0_.lastName=? In this query, "elder" is bound as a Boolean value when the column is actually a smallint. Setting deferPrepares=false would probably fix this, but that could have an undesirable impact on performance. This can be fixed by overriding Dialect.getSqlTypeDescriptorOverride(int sqlCode) for DB2Dialect to return SmallIntTypeDescriptor.INSTANCE for sqlCode == Types.BOOLEAN. This works with deferPrepares=true. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
2
0 / 0

[Hibernate-JIRA] Created: (OGM-165) Add support for the SafeMode

by Guillaume Scheibel (JIRA)

Add support for the SafeMode ---------------------------- Key: OGM-165 URL: https://hibernate.onjira.com/browse/OGM-165 Project: Hibernate OGM Issue Type: New Feature Components: datastore Affects Versions: mongodb Reporter: Guillaume Scheibel Priority: Minor Use the org.hibernate.ogm.safemode (= true | false | no set) Should we provide more options to support Majority and Fsync_safe modes as well ? Here is there a description of each mode http://www.littlelostmanuals.com/2011/11/overview-of-basic-mongodb-java-w... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

2
4
0 / 0

[Hibernate-JIRA] Created: (HHH-6960) NullPointerException in PreCollectionRemove Listener

by Kevin Jordan (JIRA)

NullPointerException in PreCollectionRemove Listener ---------------------------------------------------- Key: HHH-6960 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6960 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 4.0.0.Final Environment: Hibernate 4.0.0 to MySQL Reporter: Kevin Jordan I'm getting a NullPointerException on line 47 of EnversPreCollectionRemoveEventListenerImpl very consistently. I wasn't sure if it was due to lazy collections or not, but it seems that it fails if they're eagerly fetched or lazily fetched. I'm guessing it has something to do with getLoadedPersister() returning a null value since the comments for it say "This is only available late during the flush cycle". The stack trace is Quote: java.lang.NullPointerException at org.hibernate.envers.event.EnversPreCollectionRemoveEventListenerImpl.onPreRemoveCollection(EnversPreCollectionRemoveEventListenerImpl.java:47) at org.hibernate.action.internal.CollectionRemoveAction.preRemove(CollectionRemoveAction.java:143) at org.hibernate.action.internal.CollectionRemoveAction.execute(CollectionRemoveAction.java:104) at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:273) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:265) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:188) at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:323) at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1081) at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:315) at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTransactionCommit(JdbcTransaction.java:101) at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:175) at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:73) ... 120 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

12
39
0 / 0

[Hibernate-JIRA] Created: (HHH-7316) Collection removal actions added by DefaultAutoFlushEventListener.onAutoFlush() are not removed when flush is not needed

by Gail Badner (JIRA)

Collection removal actions added by DefaultAutoFlushEventListener.onAutoFlush() are not removed when flush is not needed ------------------------------------------------------------------------------------------------------------------------ Key: HHH-7316 URL: https://hibernate.onjira.com/browse/HHH-7316 Project: Hibernate ORM Issue Type: Bug Components: core Reporter: Gail Badner Assignee: Gail Badner Fix For: 4.1.4 If any collection removal actions are added by DefaultAutoFlushEventListener.onAutoFlush(), they need to be removed if it turns out that flush is not needed (because no updates involve the specified query spaces). Due to the fix for HHH-6862, the added collection removal actions are no longer removed from the action queue. As a result, when the session is ultimately flushed, duplicate collection actions will be added to the action queue. The first remove will execute fine, but the CollectionEntry.loadedPersister will be set to null. If Envers is used, the second remove action involving the same collection will fail with NullPointerException when EnversPreCollectionRemoveEventListenerImpl.onPreRemoveCollection() calls collectionEntry.getLoadedPersister().isInverse(). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-1124) Log level for Log#indexDirectoryNotFoundCreatingNewOne should be INFO and not WARN

by Andrej Golovnin (JIRA)

Log level for Log#indexDirectoryNotFoundCreatingNewOne should be INFO and not WARN ---------------------------------------------------------------------------------- Key: HSEARCH-1124 URL: https://hibernate.onjira.com/browse/HSEARCH-1124 Project: Hibernate Search Issue Type: Improvement Components: engine Affects Versions: 4.1.1.Final Reporter: Andrej Golovnin Priority: Minor As discussed on the mailing list the log level for Log#indexDirectoryNotFoundCreatingNewOne should be INFO: http://lists.jboss.org/pipermail/hibernate-dev/2012-May/008320.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-7315) EntityManager will not PESSIMISTIC lock a parent class of JOINED inheritance

by Bryan Varner (JIRA)

EntityManager will not PESSIMISTIC lock a parent class of JOINED inheritance ---------------------------------------------------------------------------- Key: HHH-7315 URL: https://hibernate.onjira.com/browse/HHH-7315 Project: Hibernate ORM Issue Type: Bug Components: entity-manager Affects Versions: 4.1.3, 4.1.2 Environment: Hibernate 4.1.2, 4.1.3, PostgreSQL 9.1 Reporter: Bryan Varner Given a JPA class Hierarchy like: {code} @Entity(name = "BaseThing") @Table(name = "BaseThing") @Inheritance(strategy = InheritanceType.JOINED) public abstract class BaseThing implements Serializable { private static final long serialVersionUID = 1L; @Id @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "BaseThing_id_seq") @SequenceGenerator(name = "BaseThing_id_seq", sequenceName = "BaseThing_id_seq", allocationSize = 50) @Column(name = "id", nullable = false) private Long id; @Basic(optional = false) @Column(name = "name", nullable = false, length = 48) private String name; @Version @Column(name = "version") private int version; ... } @Entity(name = "ConcreteThing") @Table(name = "ConcreteThing") @PrimaryKeyJoinColumn(name = "id", referencedColumnName = "id") public class ConcreteThing extends BaseThing { private static final long serialVersionUID = 1L; @Basic(optional = false) @Column(name = "aprop", nullable = false, length = 12) private String aProp; ... } @Entity(name = "AnotherConcreteThing") @Table(name = "AnotherConcreteThing") @PrimaryKeyJoinColumn(name = "id", referencedColumnName = "id") public class AnotherConcreteThing extends BaseThing { private static final long serialVersionUID = 1L; @Basic(optional = false) @Column(name = "anotherprop", nullable = false, length = 12) private String anotherProp; ... } {code} Invoking the following code fails to generate a query with a FOR UPDATE clause. {code} entityManager.find(BaseThing.class, 0, LockModeType.PESSIMISTIC_WRITE); {code} Inspecting the LockMode on the returned object results in the following behavior... {code} BaseThing obj = entityManager.find(BaseThing.class, 0, LockModeType.PESSIMISTIC_WRITE); // The PESSIMISTIC_WRITE lock requirement is totally ignored, and the object is returned with OPTIMISTIC. // If you try to promote the lock to PESSIMISTIC_WRITE... if (entityManager.getLockMode(obj).equals(LockModeType.OPTIMISTIC)) { entityManager.lock(obj, LockModeType.PESSIMISTIC_WRITE); } // It looks like it's succesfull if (entityManager.getLockMode(obj).equals(LockModeType.PESSIMISTIC_WRITE)) { System.out.println("Hurray!"); } // HOWEVER... There's not any SQL generated. AT ALL, by the lock() method, and there is no lock in the database. {code} So I suppose this bug it two-fold. 1.) You can't get a PESSIMISTIC lock on anything that results in a left outer join to get the polymorphic query results. 2.) You can't promote the optimistic locks for those polymorphic objects into a PESSIMISTIC lock. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues May 2012