February 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-1045) Avoid repeated construction of a ContextualException2WayBridge during MassIndexing

by Sanne Grinovero (JIRA)

Avoid repeated construction of a ContextualException2WayBridge during MassIndexing ---------------------------------------------------------------------------------- Key: HSEARCH-1045 URL: https://hibernate.onjira.com/browse/HSEARCH-1045 Project: Hibernate Search Issue Type: Improvement Components: massindexer Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.1.0.Beta2 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
3
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: ------------------------------------- Strong, as I said here 5 years ago, I think the correct solution is to alter thew DB2 dialect to use {{for read only with rs use and keep update locks}} or {{for read only with rr use and keep update locks}}. But as I also said, I am not a DB2 expert and we need help from DB2 users to verify this. Ideally we'd really just have someone to take ownership of these dialects, but we've been asking for that for 5 years as well, so I am not holding my breath on that. I am using the following resources: * http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/topic/com.ibm.db2z... * http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/topic/com.ibm.db2z... It sounds like the type of lock to request in the {{use and keep}} portion is what we need to resolve. Using {{for read only with[rs|rr]}} seems absolutely correct. That second link describes the "lock modes". We need to choose between: * {{use and keep update locks}} Will allow other transactions to read the locked row(s) but only with shared lock mode (aka only if the other transaction does not request pessimistic lock) * {{use and keep exclusive locks}} Will not allow other transactions to read the locked row(s) at all. So we are back to where we were 5 years ago :) I think we should use {{for read only with rs use and keep update locks}} or {{for read only with rr use and keep update locks}} but need some DB2 users to verify that changing the dialect that way works as anticipated by description here. > 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 > 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

12 years, 10 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-4870) Cannot determine java-type from given member [null]

by Marcial Atienzar (JIRA)

Cannot determine java-type from given member [null] --------------------------------------------------- Key: HHH-4870 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4870 Project: Hibernate Core Issue Type: Bug Components: entity-manager Affects Versions: 3.5.0-Beta-4 Environment: jdk 6u18 glassfishv3 Reporter: Marcial Atienzar Attachments: eclipse.debug, Empre.java, Prcontra.java I've tested to migrate from hibernate 3.3.2 to 3.5.0 Beta4. I've remove all hibernate*.jar from classpath and add only de hibernate3.jar I've downloaded the source off hibernate-entitymanager to debug from eclipse. I've reached the class that has the error, but I don't know what can I do to resolve it. I'm doing something wrong? I attatch the sources of the classes that takes part on eclipse debug. I don't know how to attach a testcase. The project has more than 200 entities. I've post previously in hibernate forums: https://forum.hibernate.org/viewtopic.php?f=1&t=1002363&p=2424419#p2424419 -- 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

12 years, 10 months

9
60
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-885) Update Lucene version

by Harry Callahan (JIRA)

Update Lucene version --------------------- Key: HSEARCH-885 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-885 Project: Hibernate Search Issue Type: Improvement Affects Versions: 3.4.0.Final Reporter: Harry Callahan Priority: Critical Please update Lucene version to 3.3.0 in the 3.4.x branch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

2
7
0 / 0

[Hibernate-JIRA] Created: (HHH-7086) Using "end" as variable name conflicts with end keyword in postgresql, should be escaped

by Konstantin Matuschek (JIRA)

Using "end" as variable name conflicts with end keyword in postgresql, should be escaped ---------------------------------------------------------------------------------------- Key: HHH-7086 URL: https://hibernate.onjira.com/browse/HHH-7086 Project: Hibernate ORM Issue Type: Bug Affects Versions: 4.0.1 Environment: JBoss 7.1 Final, Maven 3.0.3, EJB 3.1 Reporter: Konstantin Matuschek I created an entity class with an instance variable named "end". When trying to persist objects for the first time (table should be created), this results in: org.postgresql.util.PSQLException: ERROR: syntax error at or near "end". When invoking the command manually in psql, it works with double quotes around the string "end", but hibernate doesn't escape the keyword in this way. SQL String that Hibernate tries to use: 12:07:18,584 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (MSC service thread 1-1) HHH000389: Unsuccessful: create table project (id int8 not null, description text, end date, name varchar(255) not null, start date not null, primary key (id)) 12:07:18,585 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (MSC service thread 1-1) ERROR: syntax error at or near "end" SQL String that works (manually in psql): create table project (id int8 not null, description text, "end" date, name varchar(255) not null, start date not null, primary key (id)); Example truncated entity class: import java.util.Date; @Entity @Table(name = "project") public class Project implements Serializable, Comparable<Project> { @Transient private static final long serialVersionUID = 1L; @NotNull @Temporal(TemporalType.DATE) private Date start; @Temporal(TemporalType.DATE) private Date end; public Project() { } } -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
2
0 / 0

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

by Strong Liu (JIRA)

[ https://hibernate.onjira.com/browse/HHH-1512?page=com.atlassian.jira.plug... ] Strong Liu commented on HHH-1512: --------------------------------- confirm 1,2,5,6,7 all work with _org.hibernate.test.locking.LockModeTest_ > 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 > 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

12 years, 10 months

1
0
0 / 0

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

by Strong Liu (JIRA)

[ https://hibernate.onjira.com/browse/HHH-1512?page=com.atlassian.jira.plug... ] Strong Liu commented on HHH-1512: --------------------------------- Steve, any plan of this? seems it is the cause of HHH-7107 > 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 > 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

12 years, 10 months

1
0
0 / 0

[Hibernate-JIRA] Created: (JPA-28) Simple Query with guarded Null Value fails with Apache Derby

by Bernard (JIRA)

Simple Query with guarded Null Value fails with Apache Derby ------------------------------------------------------------ Key: JPA-28 URL: https://hibernate.onjira.com/browse/JPA-28 Project: Java Persistence API Issue Type: Bug Environment: Hibernate 3.6.9.Final derbyclient 10.8.2.2 Reporter: Bernard Priority: Critical Attachments: NullParameterHibernateMaven.zip The attached testcase is similar to http://en.wikipedia.org/wiki/Java_Persistence_Query_Language#Examples that shows a JPQL query: SELECT a FROM Author a WHERE :lastName IS NULL OR LOWER(a.lastName) = :lastName Hibernate crashes in case where the parameter value is null: org.hibernate.exception.DataException: could not execute query Caused by: java.sql.SQLDataException: An attempt was made to get a data value of type 'VARBINARY' from a data value of type 'VARCHAR'. I would expect that this type of query succeeds, because an equivalent raw JDBC testcase (included) succeeds also. String sql = "SELECT ID, NAME, region_id FROM CUSTOMERORDER WHERE ((? IS NULL) OR (region_id = ?))"; PreparedStatement pStmt = conn.prepareStatement(sql); Integer regionId = null; pStmt.setObject(1, regionId); pStmt.setObject(2, regionId); ResultSet result = pStmt.executeQuery(); Success! For some background, please see https://issues.apache.org/jira/browse/DERBY-1938 "Add support for setObject(<arg>, null)" which is included since db-derby-10.7.1.1 It would be great to see an early assessment in case this is a database driver issue not Hibernate. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-7073) Audited entities with Many-to-Many relationships fail with NullPointerException

by Clement Pang (JIRA)

Audited entities with Many-to-Many relationships fail with NullPointerException ------------------------------------------------------------------------------- Key: HHH-7073 URL: https://hibernate.onjira.com/browse/HHH-7073 Project: Hibernate ORM Issue Type: Bug Components: envers Affects Versions: 4.1.0 Reporter: Clement Pang The entity contains the following field: @ManyToMany(cascade = {CascadeType.PERSIST}) @JoinTable( name = "Apples", joinColumns = {@JoinColumn(name = "storeId", nullable = false)}, inverseJoinColumns = {@JoinColumn(name = "appleId", nullable = false)} ) public Set<Apple> apples = new HashSet<Apple>(); An exception is thrown when saving the entity: java.lang.NullPointerException at org.hibernate.envers.entities.EntitiesConfigurations.getToPropertyNames(EntitiesConfigurations.java:155) at org.hibernate.envers.event.BaseEnversEventListener.addCollectionChangeWorkUnit(BaseEnversEventListener.java:121) at org.hibernate.envers.event.BaseEnversEventListener.generateBidirectionalCollectionChangeWorkUnits(BaseEnversEventListener.java:90) at org.hibernate.envers.event.EnversPostInsertEventListenerImpl.onPostInsert(EnversPostInsertEventListenerImpl.java:60) at org.hibernate.action.internal.EntityIdentityInsertAction.postInsert(EntityIdentityInsertAction.java:149) at org.hibernate.action.internal.EntityIdentityInsertAction.execute(EntityIdentityInsertAction.java:102) In that particular method: public Set<String> getToPropertyNames(String fromEntityName, String fromPropertyName, String toEntityName) { Set<String> entityAndParentsNames = getEntityAndParentsNames(fromEntityName); Set<String> toPropertyNames = new HashSet<String>(); for (RelationDescription relationDescription : getRelationDescriptions(toEntityName)) { String relToEntityName = relationDescription.getToEntityName(); String mappedByPropertyName = relationDescription.getMappedByPropertyName(); if (entityAndParentsNames.contains(relToEntityName) && mappedByPropertyName.equals(fromPropertyName)) { toPropertyNames.add(relationDescription.getFromPropertyName()); } } return toPropertyNames; } mappedByPropertyName is null since RelationDescription can have null mappedByPropertyName when invoked at: EntityConfiguration public void addToManyMiddleRelation(String fromPropertyName, String toEntityName) { relations.put(fromPropertyName, new RelationDescription(fromPropertyName, RelationType.TO_MANY_MIDDLE, toEntityName, null, null, null, null, true)); } -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

2
7
0 / 0

[Hibernate-JIRA] Created: (HHH-7117) MultipleLinesSqlCommandExtractor does not accept trailing white spaces after last statement

by Lukasz Antoniak (JIRA)

MultipleLinesSqlCommandExtractor does not accept trailing white spaces after last statement ------------------------------------------------------------------------------------------- Key: HHH-7117 URL: https://hibernate.onjira.com/browse/HHH-7117 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 4.0.0.Final Reporter: Lukasz Antoniak Assignee: Lukasz Antoniak Priority: Minor Attachments: MultipleLinesSqlCommandExtractorAndWhiteSpace.java Files ended with white symbols are being parsed incorrectly. Thanks to Xavier Dury for reporting this issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
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 February 2012