April 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-7281) Tests fail on Postgresql due to failure in typecasting

by Madhumita Sadhukhan (JIRA)

Tests fail on Postgresql due to failure in typecasting ------------------------------------------------------ Key: HHH-7281 URL: https://hibernate.onjira.com/browse/HHH-7281 Project: Hibernate ORM Issue Type: Bug Components: testsuite Affects Versions: 4.1.2 Reporter: Madhumita Sadhukhan Assignee: Strong Liu Refer https://issues.jboss.org/browse/JBPAPP-8836 for details Quite a few tests started failing asking for explicit typecasts after upgrade of dialect in postgresql Exception which varies in failing tests but core reason is same:(for eg) org.hibernate.exception.SQLGrammarException: ERROR: operator does not exist: integer = boolean Hint: No operator matches the given name and argument type(s). You might need to add explicit type casts. Position: 427 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
1
0 / 0

[Hibernate-JIRA] Resolved: (HHH-1512) Problem to lock a row in a DB2 database with LockMode UPGRADE

by Steve Ebersole (JIRA)

[ https://hibernate.onjira.com/browse/HHH-1512?page=com.atlassian.jira.plug... ] Steve Ebersole resolved HHH-1512. --------------------------------- Resolution: Fixed > Problem to lock a row in a DB2 database with LockMode UPGRADE > ------------------------------------------------------------- > > Key: HHH-1512 > URL: https://hibernate.onjira.com/browse/HHH-1512 > Project: Hibernate ORM > Issue Type: Bug > Components: core > Affects Versions: 3.1 > Environment: DB2 v8.2, Hibernate 3.1 and higher > Reporter: Peter Potthoff > Assignee: Steve Ebersole > Fix For: 4.1.3 > > Attachments: locks.txt > > Original Estimate: 1h > Time Spent: 0.4h > Remaining Estimate: 1h > > Using the LockMode UPGRADE to lock a row in the database, this will result in > a sql-statement: select ID from <schema>.<table> where ID =? and version =? for read only with rs > This statement produces a shared lock and cannot be used for pessimistic locking because > this kind of lock won't stop a concurrent thread from accessing the data. > The source of the class DB2Dialect.java was changed from release 1.34 to 1.35: > http://cvs.sourceforge.net/viewcvs.py/hibernate/Hibernate3/src/org/hibern... > and from 1.33 to 1.34 > http://cvs.sourceforge.net/viewcvs.py/hibernate/Hibernate3/src/org/hibern... > Please take a look at: HHH-378 and http://forum.hibernate.org/viewtopic.php?t=954639&highlight=db2+lock+upgrade -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1512) Problem to lock a row in a DB2 database with LockMode UPGRADE

by Steve Ebersole (JIRA)

[ https://hibernate.onjira.com/browse/HHH-1512?page=com.atlassian.jira.plug... ] Steve Ebersole commented on HHH-1512: ------------------------------------- In reference to my last comment, this specific DB2 documentation is @ http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=%2... Especially note: {quote} To take advantage of the possibly improved performance of FETCH operations while guaranteeing that selected data is not modified and preventing some types of deadlocks, you can specify FOR READ ONLY in combination with the optional syntax of USE AND KEEP ... LOCKS on the isolation-clause. {quote} Again, keeping in mind that "selected data is not modified" is specifically in regards to positioned updates. > Problem to lock a row in a DB2 database with LockMode UPGRADE > ------------------------------------------------------------- > > Key: HHH-1512 > URL: https://hibernate.onjira.com/browse/HHH-1512 > Project: Hibernate ORM > Issue Type: Bug > Components: core > Affects Versions: 3.1 > Environment: DB2 v8.2, Hibernate 3.1 and higher > Reporter: Peter Potthoff > Assignee: Steve Ebersole > Fix For: 4.1.3 > > Attachments: locks.txt > > Original Estimate: 1h > Remaining Estimate: 1h > > Using the LockMode UPGRADE to lock a row in the database, this will result in > a sql-statement: select ID from <schema>.<table> where ID =? and version =? for read only with rs > This statement produces a shared lock and cannot be used for pessimistic locking because > this kind of lock won't stop a concurrent thread from accessing the data. > The source of the class DB2Dialect.java was changed from release 1.34 to 1.35: > http://cvs.sourceforge.net/viewcvs.py/hibernate/Hibernate3/src/org/hibern... > and from 1.33 to 1.34 > http://cvs.sourceforge.net/viewcvs.py/hibernate/Hibernate3/src/org/hibern... > Please take a look at: HHH-378 and http://forum.hibernate.org/viewtopic.php?t=954639&highlight=db2+lock+upgrade -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1512) Problem to lock a row in a DB2 database with LockMode UPGRADE

by Steve Ebersole (JIRA)

[ https://hibernate.onjira.com/browse/HHH-1512?page=com.atlassian.jira.plug... ] Steve Ebersole commented on HHH-1512: ------------------------------------- Hey Strong, Just noticing that these suggestions remove the [FOR READ ONLY] portion, and I wonder why? Was that intentional? According to the DB2 docs, [FOR READ ONLY] only refers to the resulting cursor. It is meant to indicate that the cursor will not be used in positioned updates (Hibernate never does positioned updates). It should be an optimization in our use cases. Can you confirm that? For the time being I will leave it. > Problem to lock a row in a DB2 database with LockMode UPGRADE > ------------------------------------------------------------- > > Key: HHH-1512 > URL: https://hibernate.onjira.com/browse/HHH-1512 > Project: Hibernate ORM > Issue Type: Bug > Components: core > Affects Versions: 3.1 > Environment: DB2 v8.2, Hibernate 3.1 and higher > Reporter: Peter Potthoff > Assignee: Steve Ebersole > Fix For: 4.1.3 > > Attachments: locks.txt > > Original Estimate: 1h > Remaining Estimate: 1h > > Using the LockMode UPGRADE to lock a row in the database, this will result in > a sql-statement: select ID from <schema>.<table> where ID =? and version =? for read only with rs > This statement produces a shared lock and cannot be used for pessimistic locking because > this kind of lock won't stop a concurrent thread from accessing the data. > The source of the class DB2Dialect.java was changed from release 1.34 to 1.35: > http://cvs.sourceforge.net/viewcvs.py/hibernate/Hibernate3/src/org/hibern... > and from 1.33 to 1.34 > http://cvs.sourceforge.net/viewcvs.py/hibernate/Hibernate3/src/org/hibern... > Please take a look at: HHH-378 and http://forum.hibernate.org/viewtopic.php?t=954639&highlight=db2+lock+upgrade -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-7280) Upgrade to Infinispan 5.1.4.FINAL

by Galder Zamarreno (JIRA)

Upgrade to Infinispan 5.1.4.FINAL --------------------------------- Key: HHH-7280 URL: https://hibernate.onjira.com/browse/HHH-7280 Project: Hibernate ORM Issue Type: Improvement Components: caching (L2) Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.3 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-6328) Hibernate's "Table" annotations does not cooperate well with custom quoting naming strategy

by Richard Eckart de Castilho (JIRA)

Hibernate's "Table" annotations does not cooperate well with custom quoting naming strategy ------------------------------------------------------------------------------------------- Key: HHH-6328 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6328 Project: Hibernate Core Issue Type: Bug Components: annotations Affects Versions: 3.6.5 Reporter: Richard Eckart de Castilho I have implemented a custom QuotingNamingStrategy that quotes table names, so that they are properly treated as case sensitive and to avoid issues with reserved names. I also have auxiliary "Table" annotations to have Hibernate create indexes on my behalf. Of course the table name is not quoted in these annotations: {code} @org.hibernate.annotations.Table(appliesTo="MyTable",indexes = { @Index(name="column1", columnNames="column2")}) {code} Now I get the exception: {noformat} org.hibernate.AnnotationException: @org.hibernate.annotations.Table references an unknown table: MyTable at org.hibernate.cfg.annotations.EntityBinder.processComplementaryTableDefinitions(EntityBinder.java:877) at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:733) {noformat} Debugging the issue, I find that the EntityBinder tries to match the quoted name against the "appliesTo" attribute of the Table annotation, but the value of this attribute is not processed by my custom QuotingNamingStrategy. Thus, the table cannot be found: {code} public void processComplementaryTableDefinitions(org.hibernate.annotations.Table table) { //comment and index are processed here if ( table == null ) return; String appliedTable = table.appliesTo(); Iterator tables = persistentClass.getTableClosureIterator(); Table hibTable = null; while ( tables.hasNext() ) { Table pcTable = (Table) tables.next(); // -=> Here the quoted name is compared to the unquoted name from "appliedTable" if ( pcTable.getQuotedName().equals( appliedTable ) ) { //we are in the correct table to find columns hibTable = pcTable; break; } hibTable = null; } if ( hibTable == null ) { //maybe a join/secondary table for ( Join join : secondaryTables.values() ) { if ( join.getTable().getQuotedName().equals( appliedTable ) ) { hibTable = join.getTable(); break; } } } if ( hibTable == null ) { throw new AnnotationException( "@org.hibernate.annotations.Table references an unknown table: " + appliedTable ); } if ( !BinderHelper.isEmptyAnnotationValue( table.comment() ) ) hibTable.setComment( table.comment() ); TableBinder.addIndexes( hibTable, table.indexes(), mappings ); } {code} I do believe that the value of the "appliedTo" attribute should be passed through the naming strategy before comparing against the table name. -- 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

2
1
0 / 0

[Hibernate-JIRA] Updated: (HHH-1512) Problem to lock a row in a DB2 database with LockMode UPGRADE

by Steve Ebersole (JIRA)

[ https://hibernate.onjira.com/browse/HHH-1512?page=com.atlassian.jira.plug... ] Steve Ebersole updated HHH-1512: -------------------------------- Fix Version/s: 4.1.3 Ok, so we know the proper lock clause now :) > Problem to lock a row in a DB2 database with LockMode UPGRADE > ------------------------------------------------------------- > > Key: HHH-1512 > URL: https://hibernate.onjira.com/browse/HHH-1512 > Project: Hibernate ORM > Issue Type: Bug > Components: core > Affects Versions: 3.1 > Environment: DB2 v8.2, Hibernate 3.1 and higher > Reporter: Peter Potthoff > Assignee: Steve Ebersole > Fix For: 4.1.3 > > Attachments: locks.txt > > Original Estimate: 1h > Remaining Estimate: 1h > > Using the LockMode UPGRADE to lock a row in the database, this will result in > a sql-statement: select ID from <schema>.<table> where ID =? and version =? for read only with rs > This statement produces a shared lock and cannot be used for pessimistic locking because > this kind of lock won't stop a concurrent thread from accessing the data. > The source of the class DB2Dialect.java was changed from release 1.34 to 1.35: > http://cvs.sourceforge.net/viewcvs.py/hibernate/Hibernate3/src/org/hibern... > and from 1.33 to 1.34 > http://cvs.sourceforge.net/viewcvs.py/hibernate/Hibernate3/src/org/hibern... > Please take a look at: HHH-378 and http://forum.hibernate.org/viewtopic.php?t=954639&highlight=db2+lock+upgrade -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-1109) Enable ConstantScoreAutoRewrite for wildcard queries

by Nicolas Helleringer (JIRA)

Enable ConstantScoreAutoRewrite for wildcard queries ---------------------------------------------------- Key: HSEARCH-1109 URL: https://hibernate.onjira.com/browse/HSEARCH-1109 Project: Hibernate Search Issue Type: Improvement Components: query Affects Versions: 4.1.0.Final Reporter: Nicolas Helleringer By default wildcard queries in Lucene are constant scored (they are MultiTermQueries). Hibernate Search could allow the use of MultiTermQuery.ConstantScoreAutoRewrite (http://lucene.apache.org/core/old_versioned_docs/versions/3_5_0/api/core/...) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Created: (OGM-160) Invalid persistence unit configuration might result in NullPointerException

by Sanne Grinovero (JIRA)

Invalid persistence unit configuration might result in NullPointerException --------------------------------------------------------------------------- Key: OGM-160 URL: https://hibernate.onjira.com/browse/OGM-160 Project: Hibernate OGM Issue Type: Bug Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.0-next If the persistence unit name mentioned in the configuration file is not matching the name passed to the initialization method, the Persistence provider is expected to return null. The HibernateOgmPersistence is not prepared to deal with null return values from the delegate, and returns instead an unusable EntityManagerFactory. {code} Persistence.createEntityManagerFactory( "does-not-exist-PU" ); {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HCANN-48) @AccessType. Custom PropertAccessor Hibernate does not work

by Stanislav Zaluzhskiy (JIRA)

@AccessType. Custom PropertAccessor Hibernate does not work ----------------------------------------------------------- Key: HCANN-48 URL: https://hibernate.onjira.com/browse/HCANN-48 Project: Hibernate Commons Annotations Issue Type: Bug Affects Versions: 4.0.1.Final Environment: Spring 3.1.X Reporter: Stanislav Zaluzhskiy Hi, I'm trying to migrate from Hibernate 3.5.6 to 4.1.1. Faced with several problems one of them is that @AccessType is not working. My custom Getters nad Settors are not called at anytime. Code example: @NotNull @Size(min = PASSWORD_MIN_SIZE, max = MAX_SIZE) @Pattern(regexp = "((?=.*\\d)(?=.*[a-zA-Zа-яА-Я]).*)", message = "{javax.validation.constraints.Pattern.password.message}") @Column(name = "user_password", nullable = false) @AccessType(value = "com.utils.PasswordPropertyAccessor") private String password; -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues April 2012