[Hibernate-JIRA] Created: (HHH-2588) Incorrect database updates with "generated" fields in record
by Frits Jalvingh (JIRA)
Incorrect database updates with "generated" fields in record
------------------------------------------------------------
Key: HHH-2588
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2588
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.3, 3.2.0.ga
Environment: Tested with Hibernate 3.2.3 and 3.2.0GA, Oracle 10gR2, Linux, Java 5.
Reporter: Frits Jalvingh
I have a single POJO (UserGroup) which is based on a superclass which defines a number of properties as @Generated(GenerationTime.INSERT); amongst others tcn and ros_id. These properties are defined as "not null" in the database, and are filled in by an insert database trigger.
When I create a new instance and do this:
--------------------
Transaction tr = getSession().beginTransaction();
UserGroup ug = new UserGroup();
ug.setType(UserGroupType.PLN);
ug.setName(name);
ug.setDescription(desc);
getSession().save(ug); // persist() exhibits the same problem...
ug.setGroupEmail("jaja(a)nono.com");
tr.commit();
--------------------
I get a database exception: ORA-01407: cannot update ("TEST"."CRM_GROUPS"."ROS_ID") to NULL
When I look at the persister's logging I see something very wrong happening:
--------------------
DEBUG - commit
DEBUG - automatically flushing session
DEBUG - flushing session
DEBUG - processing flush-time cascades
DEBUG - dirty checking collections
DEBUG - Flushing entities and processing referenced collections
DEBUG - nl.itris.viewpoint.db.crm.UserGroup.groupEmail is dirty
DEBUG - nl.itris.viewpoint.db.crm.UserGroup.memberMutable is dirty
DEBUG - Updating entity: [nl.itris.viewpoint.db.crm.UserGroup#1150000159]
DEBUG - nl.itris.viewpoint.db.crm.UserGroup.groupEmail is dirty
DEBUG - nl.itris.viewpoint.db.crm.UserGroup.memberMutable is dirty
DEBUG - Collection found: [nl.itris.viewpoint.db.crm.UserGroup.memberList#1150000159], was: [<unreferenced>] (initialized)
DEBUG - Processing unreferenced collections
DEBUG - Scheduling collection removes/(re)creates/updates
DEBUG - Flushed: 1 insertions, 1 updates, 0 deletions to 1 objects
DEBUG - Flushed: 1 (re)creations, 0 updates, 0 removals to 1 collections
DEBUG - listing entities:
DEBUG - nl.itris.viewpoint.db.crm.UserGroup{groupEmail=jal(a)etc.to, memberList=[], type=PLN, tcn=null, logTime=null, logModule=null, id=1150000159, organisationId=null, groupLeader=null, description=test2, memberMutable=null, logDate=null, name=test2, logUser=null}
DEBUG - executing flush
DEBUG - registering flush begin
DEBUG - Inserting entity: [nl.itris.viewpoint.db.crm.UserGroup#1150000159]
DEBUG - about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
DEBUG - insert into CRM_GROUPS (CGP_DESCRIPTION, CGP_GROUPEMAIL, CST_ID, CGP_MEMBER_MUTABLE, CGP_NAME, CGP_TYPE, CGP_ID) values (?, ?, ?, ?, ?, ?, ?)
DEBUG - preparing statement
DEBUG - Dehydrating entity: [nl.itris.viewpoint.db.crm.UserGroup#1150000159]
DEBUG - binding 'test2' to parameter: 1
DEBUG - binding null to parameter: 2
DEBUG - binding null to parameter: 3
DEBUG - binding 'test2' to parameter: 5
DEBUG - Binding 'PLN' to parameter: 6
DEBUG - binding '1150000159' to parameter: 7
DEBUG - Executing batch size: 1
DEBUG - success of batch update unknown: 0
DEBUG - about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
DEBUG - closing statement
DEBUG - about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
DEBUG - select usergroup_.LOG_DATE as LOG2_74_, usergroup_.LOG_MODULE as LOG3_74_, usergroup_.LOG_TIME as LOG4_74_, usergroup_.LOG_USER as LOG5_74_, usergroup_.TCN as TCN74_, usergroup_.ROS_ID as ROS7_74_ from CRM_GROUPS usergroup_ where usergroup_.CGP_ID=?
DEBUG - preparing statement
DEBUG - binding '1150000159' to parameter: 1
DEBUG - about to open ResultSet (open ResultSets: 0, globally: 0)
DEBUG - returning '2007-04-26 00:00:00' as column: LOG2_74_
DEBUG - returning null as column: LOG3_74_
DEBUG - returning '14:28:04' as column: LOG4_74_
DEBUG - returning 'VPC' as column: LOG5_74_
DEBUG - returning '310525020' as column: TCN74_
DEBUG - returning '1500' as column: ROS7_74_
DEBUG - about to close ResultSet (open ResultSets: 1, globally: 1)
DEBUG - Updating entity: [nl.itris.viewpoint.db.crm.UserGroup#1150000159]
DEBUG - about to open PreparedStatement (open PreparedStatements: 1, globally: 1)
DEBUG - update CRM_GROUPS set TCN=?, ROS_ID=?, CGP_DESCRIPTION=?, CGP_GROUPEMAIL=?, CST_ID=?, CGP_MEMBER_MUTABLE=?, CGP_NAME=?, CGP_TYPE=? where CGP_ID=?
DEBUG - preparing statement
DEBUG - Dehydrating entity: [nl.itris.viewpoint.db.crm.UserGroup#1150000159]
DEBUG - binding null to parameter: 1
DEBUG - binding null to parameter: 2
DEBUG - binding 'test2' to parameter: 3
DEBUG - binding 'jal(a)etc.to' to parameter: 4
DEBUG - binding null to parameter: 5
DEBUG - binding 'test2' to parameter: 7
DEBUG - Binding 'PLN' to parameter: 8
DEBUG - binding '1150000159' to parameter: 9
DEBUG - Executing batch size: 1
DEBUG - about to close PreparedStatement (open PreparedStatements: 2, globally: 2)
DEBUG - closing statement
DEBUG - Could not execute JDBC batch update [update CRM_GROUPS set TCN=?, ROS_ID=?, CGP_DESCRIPTION=?, CGP_GROUPEMAIL=?, CST_ID=?, CGP_MEMBER_MUTABLE=?, CGP_NAME=?, CGP_TYPE=? where CGP_ID=?]
to.etc.dbpool.BetterSQLException: java.sql.BatchUpdateException: ORA-01407: cannot update ("VIEWPOINT"."CRM_GROUPS"."ROS_ID") to NULL
SQL: update CRM_GROUPS set TCN=?, ROS_ID=?, CGP_DESCRIPTION=?, CGP_GROUPEMAIL=?, CST_ID=?, CGP_MEMBER_MUTABLE=?, CGP_NAME=?, CGP_TYPE=? where CGP_ID=?
Parameters:
#1:[null]
#2:[null]
#3:java.lang.String:test2
#4:java.lang.String:jal@etc.to
#5:[null]
#6:java.lang.String:N
#7:java.lang.String:test2
#8:java.lang.String:PLN
#9:java.lang.Long:1150000159
at to.etc.dbpool.PreparedStatementProxy.wrap(PreparedStatementProxy.java:68)
at to.etc.dbpool.StatementProxy.executeBatch(StatementProxy.java:176)
at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:48)
at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:246)
at org.hibernate.persister.entity.AbstractEntityPersister.processGeneratedProperties(AbstractEntityPersister.java:3691)
at org.hibernate.persister.entity.AbstractEntityPersister.processUpdateGeneratedProperties(AbstractEntityPersister.java:3680)
at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:124)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:248)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:232)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:140)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106)
at nl.itris.moca.ajax.Planner.updatePlanGroup(Planner.java:1717)
----------------------------------
Hibernate starts by inserting the new record correctly, and then reselects the inserted record to retrieve the changed fields correctly. But after that it does an update of that record with stale data: it sets all of the generated fields it *has* read to null, and updates the groupEmail field which for some reason was not present in the insert!?
It looks like multiple versions of the same records are maintained in some way??
The problem is triggered by the existence of the "save" call *followed by* another change to the record. But the same problem occurs when other things cause an intermediary update, for instance when trying to save the data in a collection parented by UserGroup.
Because this problem also occurs when I add/change elements in the UserGroup's associated GroupMember one-to-many association I am effectively unable to store a group with it's members in one transaction!
In addition I noticed that the persist() call seems to check defined constraints on the record at the time persist() is called instead of the time that it gets commited. This means it can only be called when the pojo is complete which looks odd to me? I sort of understand this for save() as that is required to return the primary key but I do not understand why this is needed for persist...
--
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
18 years, 2 months
[Hibernate-JIRA] Created: (HHH-3083) Incorrect delete handling
by Krashan Brahmanjara (JIRA)
Incorrect delete handling
-------------------------
Key: HHH-3083
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3083
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.5
Environment: 3.2.5.ga
Reporter: Krashan Brahmanjara
When user try to delete not existing row from database see long exception message.
Real databases like Informix report status=0 and don't report any error in this case and users probably expect the same from Hibernate. I think that should be rather NotFoundException than org.hibernate.StaleStateException etc.
I see this error also when hibernate.jdbc.batch_size is 0 a
Current exception trace in this case
2008-01-24 15:48:43 org.hibernate.event.def.AbstractFlushingEventListener performExecutions
SEVERE: Could not synchronize database state with session
org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1
at org.hibernate.jdbc.Expectations$BasicExpectation.checkBatched(Expectations.java:61)
at org.hibernate.jdbc.Expectations$BasicExpectation.verifyOutcome(Expectations.java:46)
at org.hibernate.jdbc.NonBatchingBatcher.addToBatch(NonBatchingBatcher.java:24)
at org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:2520)
at org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:2697)
at org.hibernate.action.EntityDeleteAction.execute(EntityDeleteAction.java:74)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:234)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:146)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106)
--
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
18 years, 2 months
[Hibernate-JIRA] Commented: (HHH-468) MysqlDialect incorrectly maps java.lang.Boolean to SQL BIT
by Lieven Doclo (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-468?page=co... ]
Lieven Doclo commented on HHH-468:
----------------------------------
To bring this issue back to life:
Can't we just map BIT to tinyint(1) in the MySQL dialect. This seems okay for all MySQL dialects (MyISAM and InnoDB).
One of the problems with bit in MySQL is that standard it's not show in a MySQL console. For example:
"select bitField from testTable" = field values not shown in console. You have to use "select BIT(bitField) from testTable" or "select bitField+0 from testTable" to show the values. When using tinyint(1), you don't encounter this problem.
So please fix this.
> MysqlDialect incorrectly maps java.lang.Boolean to SQL BIT
> ----------------------------------------------------------
>
> Key: HHH-468
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-468
> Project: Hibernate3
> Issue Type: Bug
> Affects Versions: 3.0.3
> Environment: Hibernate 3.0, MySQL.
> Reporter: Mark Matthews
> Assignee: Scott Marlow
>
> I didn't track down how java.lang.Boolean gets mapped to Types.BIT in hibernate, but you probably _don't_ want to map to "bit" like you do in MysqlDialect.
> "bit", according to SQL99 (it's not in the core standard, and the type was actually dropped for sql2k3) is a bitfield, not a boolean value. You can of course define a bit(1), but it is technically more correct for java.lang.Boolean to map to a SQL BOOLEAN for MySQL since we support a BOOLEAN and a BIT.
> It looks like the JDBC-3.0 guys ignored what the standard said, because in reality you'd want BIT to map to something like byte[], or java.util.BitSet if you were tracking how the SQL standard defines BIT.
> I'm guessing you probably want to map to "boolean", which the JDBC driver will automagically convert for you, as it silently maps to TINYINT(1) on the server side.
--
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
18 years, 2 months
[Hibernate-JIRA] Created: (HHH-3082) JPQL constructor_expression followed by an aggregate_expression in select_clause not supported
by Bob Tiernay (JIRA)
JPQL constructor_expression followed by an aggregate_expression in select_clause not supported
----------------------------------------------------------------------------------------------
Key: HHH-3082
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3082
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Reporter: Bob Tiernay
>From the JPA spec:
select_statement ::= select_clause from_clause [where_clause] [groupby_clause] [having_clause] [orderby_clause]
select_clause ::= SELECT [DISTINCT] select_expression {, select_expression}*
select_expression ::= single_valued_path_expression | aggregate_expression | identification_variable | OBJECT(identification_variable)| constructor_expression
constructor_expression ::= NEW constructor_name( constructor_item {, constructor_item}*)
Expanding the production rules confirms that select_clause should support both a constructor_expression and an aggregate_expression in sequence. For example:
SELECT NEW package.DTO(e.f), COUNT(e) FROM Entity e WHERE ...
However, doing so indicates a grammar error in the "," prior to the aggregate expression.
--
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
18 years, 2 months
[Hibernate-JIRA] Created: (HBX-1037) Reverse engineering doesn't match all tables
by Alessandro (JIRA)
Reverse engineering doesn't match all tables
--------------------------------------------
Key: HBX-1037
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1037
Project: Hibernate Tools
Issue Type: Bug
Affects Versions: 3.2.0.GA
Environment: Jdk 5.0, linux, Oracle and MySQL
Reporter: Alessandro
The table filter doesn't match all tables I want, either with the pattern ".*" or with the full name description of all tables.
It seems the reverse engineering has problem with long name tables. Anyway, if I choose only some tables with the long name, the reverse engineering works...
This debug seems to find all tables:
{TABLE_SCHEM=GESTIONE_PROTOCOLLO_TEST, REMARKS=null, TABLE_CAT=null, TABLE_NAME=RISERVATEZZA, TABLE_TYPE=TABLE}
but the "hbm.xml" files aren't generated.
Some ideas?
Thank you very much!
--
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
18 years, 2 months