[Hibernate-JIRA] Updated: (HHH-1819) Invalid SQL generated for mapping with property-ref
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1819?page=all ]
Steve Ebersole updated HHH-1819:
--------------------------------
Fix Version: (was: 3.3)
antlr-rework
> Invalid SQL generated for mapping with property-ref
> ---------------------------------------------------
>
> Key: HHH-1819
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1819
> Project: Hibernate3
> Type: Bug
> Components: query-hql
> Versions: 3.1.3
> Environment: Oracle 8.1.7
> Reporter: Jakub Mendys
> Assignee: Steve Ebersole
> Priority: Minor
> Fix For: antlr-rework
>
>
> Consider mappings:
> <class name="MedDRATerm" table="MBROW_MEDDRA_TERMS" mutable="false"
> batch-size="50">
> <cache usage="read-only" region="dictionary" />
> <id name="medDRATermId" type="long" column="TERM_ID">
> <generator class="assigned" />
> </id>
> <map name="termNames" table="MBROW_TERM_NAMES" lazy="true"
> batch-size="50">
> <cache usage="read-only" region="dictionary" />
> <key column="MEDDRA_CODE" property-ref="medDRACode" />
> <index column="LANGUAGE_ID"
> type="com.roche.dss.meddra.dao.type.LanguageType" />
> <element column="NAME" type="string" />
> </map>
> <property name="medDRACode" column="MEDDRA_CODE"
> type="com.roche.dss.meddra.dao.type.MedDRACodeType" />
> </class>
> <class name="MedDRATermInstance" table="MBROW_MEDDRA_TREES"
> mutable="false">
> <cache usage="read-only" region="dictionary" />
> <id name="medDRATermInstanceId" type="long" column="NODE_ID">
> <generator class="assigned" />
> </id>
> <many-to-one name="medDRATerm" class="MedDRATerm"
> column="TERM_ID" fetch="join" not-null="true" insert="false"
> update="false" />
> </class>
> and a HQL query:
> from MedDRATermInstance i where i.medDRATermInstanceId is not null and i.medDRATerm.termNames[1] like 'headache'
> Having this Hibernate will generate following SQL:
> SELECT ...
> FROM orcl_gthes.mbrow_meddra_trees meddraterm0_,
> orcl_gthes.mbrow_term_names termnames2_
> WHERE meddraterm1_.meddra_code = termnames2_.meddra_code
> AND termnames2_.language_id = 1
> AND meddraterm0_.term_id = meddraterm1_.term_id
> AND (termnames2_.NAME LIKE 'headache')
> Please note that WHERE clause refers to alias meddraterm1_ which is not mentioned in FROM section!!!!
--
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
17 years, 6 months
[Hibernate-JIRA] Created: (HHH-2516) hibernate.use_identifier_rollback=true doesn't seem to be having any effect
by Darren Clarke (JIRA)
hibernate.use_identifier_rollback=true doesn't seem to be having any effect
---------------------------------------------------------------------------
Key: HHH-2516
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2516
Project: Hibernate3
Type: Bug
Versions: 3.2.2
Environment: Tested with Hibernate 3.2.0 GA and also 3.2.2 GA Core and Annotations+EntityManager 3.3.0 GA.
MySQL Standard 5.0.27. Java 1.5.0_06 (on Mac OS X).
Reporter: Darren Clarke
Attachments: testfiles.zip
As per post entitled "Unexpected 'detached entity passed to persist' error" in the "Hibernate Annotations, EntityManager, Search, Validator, Shards" forum, original posting by darrenclarke.
I have a Person entity that has a 1:1 with an Address entity. Both have int PKs. Person has an additional unique column (accountNumber).
When I persist() a new Person that has an accountNumber that causes a unique-constraint violation (deliberately for testing purposes), catch the resulting exception and perform a rollback(), the database state is correct, but the application's internal entity state is incorrect (person.getId()==0, but person.getAddress().getId() is not 0, i.e. the PK value has not been rolled back).
Emmanuel suggested using hibernate.use_identifier_rollback=true, but that has made no difference.
The attached files replicate the problem (note I haven't performed proper ThreadLocal-based EntityManager creation and the like, it's just a bare-bones standalone example to replicate the problem).
Running Main and then stepping through the stdout reveals the following:
[stdout] Creating person 1 ...
[stdout] Persisting person 1 ...
[stdout] Prior to merge/persist, person.getId()=0, person.getAddress().getId()=0
[stdout] merge/persist succeeded.
[stdout] Creating person 2 (accountNumber is the same as person 1's) ...
[stdout] Persisting person 2 ...
[stdout] Prior to merge/persist, person.getId()=0, person.getAddress().getId()=0
[stdout] Prior to rollback, person.getId()=0, person.getAddress().getId()=2
[stdout] After rollback, person.getId()=0, person.getAddress().getId()=2
[stdout] Creation of new person failed due to duplicate account number (1) - retrying with different account number (2, retry# 1) ...
[stdout] Prior to merge/persist, person.getId()=0, person.getAddress().getId()=2
[stdout] Prior to rollback, person.getId()=0, person.getAddress().getId()=2
[stdout] After rollback, person.getId()=0, person.getAddress().getId()=2
[stdout] Exception whilst persisting person 2:
java.lang.Exception: Unable to save person
[snip]
Caused by: javax.persistence.PersistenceException: org.hibernate.PersistentObjectException: detached entity passed to persist: testapp.domain.Address
[snip]
I.e. the first persist is fine. The second persist (with unique-constraint violation) fails, but the address ID isn't reset after the rollback. Therefore when the second persist is retried with a valid accountNumber, the persist fails again as it believes an existing but detached address is referenced.
--
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
17 years, 6 months
[Hibernate-JIRA] Commented: (HBX-548) FAQ. DESCSTAT=YES required for DB2 on z/OS
by Max Rydahl Andersen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-548?page=co... ]
Max Rydahl Andersen commented on HBX-548:
-----------------------------------------
cool.
> FAQ. DESCSTAT=YES required for DB2 on z/OS
> ------------------------------------------
>
> Key: HBX-548
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-548
> Project: Hibernate Tools
> Type: Improvement
> Components: reverse-engineer
> Versions: 2.1, 3.0alpha, 3.0alpha2, 3.0alpha3, 3.0beta1, 3.0beta2, 3.0alpha4, 3.0beta3, 3.1beta4, 3.1alpha5, 3.1beta1, 3.1beta2, 3.1beta3, 3.2LATER
> Environment: DB2 os/390
> Reporter: Matthew Aston
> Priority: Trivial
> Attachments: DB2OS390MetaDataDialect.java
>
>
> When using Hibernate Tools with DB2 on z/OS (Mainframe), be aware that you need to set DESCSTAT=YES and rebind the packages in order for getMetaData().getColumns etc to work. NB. setting this will slightly increase your package size on DB2.
> The reason for this is that within the Hibernate Tools class, org.hibernate.cfg.reveng.dialect.JDBCMetaDataDialect, calls are made with the column name, e.g. rs.getString("INDEX_NAME"). DB2 will not provide the column names without the DESCSTAT setting. i.e. positioning works e.g. rs.getString(3). DB2 calls a packages SYSIBM.SQLTABLES, SYSIBM.SQLCOLUMNS etc.
> Alternately you can implement your own org.hibernate.cfg.reveng.dialect.MetaDataDialect that works around this limitation.
--
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
17 years, 6 months
[Hibernate-JIRA] Created: (HSHARDS-1) Support for replicated data
by Max Ross (JIRA)
Support for replicated data
---------------------------
Key: HSHARDS-1
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSHARDS-1
Project: Hibernate Shards
Type: New Feature
Components: engine
Versions: 3.0.0.Beta1
Environment: all environments
Reporter: Max Ross
Assigned to: Max Ross
It's currently difficult to deal with replicated, slow-changing data. For example, you might have a Country table on all your shards with the same data and the guarantee that this data will never change. You'd want to create associations to Country objects in your domain model too. So now suppose you want to create a new persistent object with an association to a Country. First off, your query to lookup that country by id is going to return 1 Country per shard. That in and of itself is a problem, but supposing we could do something to make it return just one shard. How do we guarantee that we get the Country that lives on the shard that the object is going to be saved on? We haven't even gone through shard selection yet! So anyway, yeah, we need to address this. Enhancing the cross-shard relationship detection interceptor to "swap" out the wrong Country instance for the right Country instance seems like an interesting idea.
--
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
17 years, 6 months
[Hibernate-JIRA] Updated: (HBX-548) FAQ. DESCSTAT=YES required for DB2 on z/OS
by Norm Lee (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-548?page=all ]
Norm Lee updated HBX-548:
-------------------------
Attachment: DB2OS390MetaDataDialect.java
Since I was unable to get the packages rebound on the mainframe, I created a new dialect named DB2OS390MetaDataDialect. Instead of using column names, the ordinal position is used when referencing the result set.
I have tested this with both Version 7 and Version 8 of DB2 on OS/390.
> FAQ. DESCSTAT=YES required for DB2 on z/OS
> ------------------------------------------
>
> Key: HBX-548
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-548
> Project: Hibernate Tools
> Type: Improvement
> Components: reverse-engineer
> Versions: 2.1, 3.0alpha, 3.0alpha2, 3.0alpha3, 3.0beta1, 3.0beta2, 3.0alpha4, 3.0beta3, 3.1beta4, 3.1alpha5, 3.1beta1, 3.1beta2, 3.1beta3, 3.2LATER
> Environment: DB2 os/390
> Reporter: Matthew Aston
> Priority: Trivial
> Attachments: DB2OS390MetaDataDialect.java
>
>
> When using Hibernate Tools with DB2 on z/OS (Mainframe), be aware that you need to set DESCSTAT=YES and rebind the packages in order for getMetaData().getColumns etc to work. NB. setting this will slightly increase your package size on DB2.
> The reason for this is that within the Hibernate Tools class, org.hibernate.cfg.reveng.dialect.JDBCMetaDataDialect, calls are made with the column name, e.g. rs.getString("INDEX_NAME"). DB2 will not provide the column names without the DESCSTAT setting. i.e. positioning works e.g. rs.getString(3). DB2 calls a packages SYSIBM.SQLTABLES, SYSIBM.SQLCOLUMNS etc.
> Alternately you can implement your own org.hibernate.cfg.reveng.dialect.MetaDataDialect that works around this limitation.
--
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
17 years, 6 months
[Hibernate-JIRA] Created: (HHH-2513) WARN logged during deserialization of replicated SessionFactory
by Brian Stansberry (JIRA)
WARN logged during deserialization of replicated SessionFactory
---------------------------------------------------------------
Key: HHH-2513
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2513
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.1
Environment: 2 Clustered JBoss AS 4.2.0.CR1 servers
Identically configured persistence unit deployed on both servers
Session factories are named via hibernate.session_factory_name
Replicated EJB3 SFSBs that have a @PersistenceContext(type=PersistenceContextType.EXTENDED) field
Reporter: Brian Stansberry
Priority: Minor
With above described environment I'm replicating an EntityManager as a field in an SFSB.
When the EM is deserialized on the remote VM, the following logging occurs:
2007-03-22 16:44:04,468 DEBUG [org.hibernate.impl.SessionFactoryObjectFactory] lookup: uid=8a8b8e6b117b997a01117b9a5b7f0001
2007-03-22 16:44:04,468 WARN [org.hibernate.impl.SessionFactoryObjectFactory] Not found: 8a8b8e6b117b997a01117b9a5b7f0001
2007-03-22 16:44:04,468 DEBUG [org.hibernate.impl.SessionFactoryObjectFactory] {8a8b8e6b117b99a101117b9a694b0001=org.hibernate.impl.SessionFactoryImpl@1f08e98}
2007-03-22 16:44:04,468 DEBUG [org.hibernate.impl.SessionFactoryObjectFactory] lookup: name=tempdb
2007-03-22 16:44:04,484 DEBUG [org.hibernate.impl.SessionFactoryImpl] deserialized: 8a8b8e6b117b997a01117b9a5b7f0001
The WARN is disconcerting, since in this case the deserialization works fine.
I've gotten the SFSB replication logic tweaked so the deserialization only happens if the SFSB client fails over to the remote VM, so having a WARN isn't the end of the world (but not having it would be nice.) If the WARN is necessary a more descriptive message would be good.
This happens because SessionFactoryImpl.deserialize() calls SessionFactoryObjectFactory.getInstance(uuid) and then calls SessionFactoryObjectFactory.getNamedInstance(name) if getInstance() returns null. The getInstance() call is the one logging the WARN.
--
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
17 years, 6 months
[Hibernate-JIRA] Created: (ANN-585) New @Persister annotation doesn't declare a default for impl target
by Shawn Clowater (JIRA)
New @Persister annotation doesn't declare a default for impl target
-------------------------------------------------------------------
Key: ANN-585
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-585
Project: Hibernate Annotations
Type: Bug
Components: binder
Versions: 3.3.0.ga
Reporter: Shawn Clowater
Not sure if this is a bug in the Annotations side of things but the new @Persister annotation doesn't define a default for the impl target. There is at least one 3rd party library that I know of (apt) that dies a horrible death when trying to parse the @Persister annotation. It blows a Null Pointer Exception when trying to look for the default.
Looking at the other annotations it would seem most if not all define a default. The drawback is that the default has to be an actual class, it doesn't seem to accept NULL. I just rolled out into our codebase with a hack that made the default Object.class so that it would compile and parse correctly. I'm not sure if that's the actual solution or not. I would think maybe SingleEntityPersister would be a better default perhaps.
--
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
17 years, 6 months
[Hibernate-JIRA] Commented: (HHH-511) reattach object from same session
by Markus Bäurle (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-511?page=co... ]
Markus Bäurle commented on HHH-511:
-----------------------------------
What is the current state of this bug?
I think the priority should be raised at least to major, because the needed workarounds are really ugly. What about the patch? Can it be applied into a new hibernate version?
I have the scenario above: The first transactional method throws an exception and the transaction is therefor rollbacked causing a clear() on the session. The following updates do not work anymore with the famous error message: Found two representations of same collection...
I use Spring with a HibernateInterceptor so I just cannot throw the session away and create a new one.
I solved the problem with a call to Session.merge() before update(), but this solution is ugly because merge() creates a new persistent instance, so I have to replace all references to the old detached instance with the new attached persistent instance. Unlike the scenario above I cannot use refresh() because it overwrites the current state with the state from the db discarding all changes.
> reattach object from same session
> ---------------------------------
>
> Key: HHH-511
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-511
> Project: Hibernate3
> Type: Bug
> Components: core
> Reporter: Gavin King
> Priority: Minor
> Attachments: reattach-same-session.patch, reattach-same-session.patch
>
>
> http://forum.hibernate.org/viewtopic.php?p=2231400#2231400
> There is a problem when you reattach a collection to the same session that it was previously attached to, after calling clear(). Hibernate checks the collections session reference, at reattach and concludes it is already attached.
--
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
17 years, 6 months