[Hibernate-JIRA] Created: (HV-246) BeanValidationEventListener has a bug (technically a problem with hibernate-annotations 3.5.0beta1... but I couldn't find that project)
by Ken Egervari (JIRA)
BeanValidationEventListener has a bug (technically a problem with hibernate-annotations 3.5.0beta1... but I couldn't find that project)
---------------------------------------------------------------------------------------------------------------------------------------
Key: HV-246
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-246
Project: Hibernate Validator
Issue Type: Bug
Affects Versions: 4.0.0.CR1
Environment: hibernate 3.3.2ga, hibernate validator 4.0cr1, hibernate-annotations 3.5.0beta1
Reporter: Ken Egervari
Priority: Blocker
The interaction with a hibernate session and sessions created within a validator do not work together.
For example, here is a test case:
{code}
@Test
public void jobSeekersCanSaveAPreviousResumeWithTheSameName() {
JobSeekerResume resume = ( JobSeekerResume ) resumeDao.find( 1 );
resume.setDescription( "new desc." );
resumeDao.save( resume );
flush();
jdbcMap = simpleJdbcTemplate.queryForMap(
"select * from resume where resume_id = ?", resume.getId() );
assertEquals( resume.getDescription(), jdbcMap.get( "DESCRIPTION" ) );
}
{code}
the flush() method creates an exception:
{code}
ERROR AssertionFailure:45 - an assertion failure occured (this may indicate a bug in Hibernate, but is more likely due to unsafe use of the session)
org.hibernate.AssertionFailure: collection [jawbs.domain.jobseeker.JobSeeker.categories] was not processed by flush()
at org.hibernate.engine.CollectionEntry.postFlush(CollectionEntry.java:228)
at org.hibernate.event.def.AbstractFlushingEventListener.postFlush(AbstractFlushingEventListener.java:356)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:51)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1028)
at jawbs.DatabaseTests.flush(DatabaseTests.java:113)
{code}
Obviously hibernate core is saying this could be a bug, or it could be unsafe.
Now, the reason this happens is because JobSeekerResume has a contraint that accesses the hibernate session. Now, I have many, many constraints that use this constraint and they work fine. This is the only test that is causing problems for me, and I don't have a clue why.
Nonetheless, I'm going to give you a lot of code. Here is the constraint annotation on JobSeekerResume:
{code}
@QueryConstraint(
hql = "select count(*) from JobSeekerResume where name = :name and id != :id and jobSeeker.id = :jobSeeker.id",
message = "{jobSeekerResume.name.unique}",
enabled = true
)
{code}
And here is the code for the validator implementation:
{code}
public class QueryConstraintValidator extends ValidatorSupport<QueryConstraint,DomainObject> {
/* Fields */
private String hql;
private boolean enabled;
/* Services */
public void initialize( QueryConstraint queryConstraint ) {
this.hql = queryConstraint.hql();
this.enabled = queryConstraint.enabled();
}
public boolean isValid( DomainObject domainObject ) {
return isValid( domainObject, null );
}
@Override
protected boolean preValidate() {
return !enabled;
}
protected boolean testQuery( Session session, DomainObject domainObject ) {
logger.debug( "Enabled - Validating constraint with: " );
logger.debug( hql );
Query query = session.createQuery(
HqlParser.removePeriodsFromParameterNames( hql )
);
BeanWrapper beanWrapper = new BeanWrapperImpl( domainObject );
for( String parameterName : HqlParser.getParameterNames( hql ) ) {
query.setParameter(
HqlParser.removePeriodsFromParameterName( parameterName ),
beanWrapper.getPropertyValue( parameterName )
);
}
boolean result = (Long) query.uniqueResult() == 0;
logger.debug( "isValid is returning: " + result );
return result;
}
...
}
{code}
The support constraint (the important one most likely) is as follows:
{code}
public abstract class ValidatorSupport<T extends Annotation,U> implements ConstraintValidator<T,U> {
/* Fields */
protected static Logger logger =
LoggerFactory.getLogger( QueryConstraintValidator.class );
/* Services */
public boolean isValid( U object, ConstraintValidatorContext constraintValidatorContext ) {
if( preValidate() ) {
return true;
}
SessionFactory sessionFactory =
( SessionFactory ) ApplicationContextProvider.getBean(
"sessionFactory" );
if( sessionFactory != null ) {
Session session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();
boolean result = testQuery( session, object );
tx.commit();
session.close();
return result;
}
return true;
}
protected boolean preValidate() {
return false;
}
protected abstract boolean testQuery( Session session, U object );
}
{code}
Lastly, here is the mapping of the JobSeeker subclass:
{code}
<subclass name="jawbs.domain.jobseeker.JobSeeker" discriminator-value="ROLE_JOBSEEKER">
<property name="isPrivate" column="is_private" />
<bag name="categories" table="job_seeker_to_category" cascade="all-delete-orphan" inverse="true">
<key column="job_seeker_id"/>
<many-to-many class="jawbs.domain.Category" column="category_id"/>
</bag>
<bag name="watchedJobs" table="job_seeker_to_watched_job" cascade="all-delete-orphan" inverse="true">
<key column="job_seeker_id"/>
<many-to-many class="jawbs.domain.job.Job" column="watched_job_id"/>
</bag>
<bag name="applications" table="candidate" cascade="all-delete-orphan" inverse="true">
<key column="job_seeker_id"/>
<many-to-many class="jawbs.domain.candidate.Candidate" column="candidate_id"/>
</bag>
<bag name="blacklistedEmployers" table="job_seeker_to_blacklisted_employer">
<key column="job_seeker_id"/>
<many-to-many class="jawbs.domain.employer.Employer" column="blacklisted_employer_id"/>
</bag>
<bag name="resumes" table="resume" inverse="true" cascade="all-delete-orphan">
<key column="job_seeker_id"/>
<one-to-many class="jawbs.domain.resume.Resume" />
</bag>
</subclass>
{code}
And here is the mapping of the subclass of resume:
{code}
<subclass name="jawbs.domain.resume.JobSeekerResume" discriminator-value="JOBSEEKER">
<many-to-one name="jobSeeker" class="jawbs.domain.jobseeker.JobSeeker"
column="job_seeker_id" />
</subclass>
{code}
If you need any more assistance, please let me know. This is a critical blocker to getting a test to pass, this is most likely 100% fine.
Thanks
--
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
14 years, 2 months
[Hibernate-JIRA] Commented: (HHH-1088) IdentifierProjection does not work with composite keys
by Thierry Rietsch (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1088?page=c... ]
Thierry Rietsch commented on HHH-1088:
--------------------------------------
We do have exactly the same problem. Why does this issue doesn't get solved?
> IdentifierProjection does not work with composite keys
> ------------------------------------------------------
>
> Key: HHH-1088
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1088
> Project: Hibernate Core
> Issue Type: Bug
> Components: query-criteria
> Affects Versions: 3.1 rc2
> Reporter: Max Muermann
> Attachments: CompositeIdProjection.java, CriteriaLoader.java
>
>
> When working with Criteria queries, the IdentifierProjection breaks if the entity has a composite key.
> In IdentifierProjection.java:
> public String toSqlString(Criteria criteria, int position, CriteriaQuery criteriaQuery)
> throws HibernateException {
> StringBuffer buf = new StringBuffer();
> String[] cols = criteriaQuery.getIdentifierColumns(criteria);
> for ( int i=0; i<cols.length; i++ ) {
> buf.append( cols[i] )
> .append(" as y")
> .append(position + i)
> .append('_');
> }
> return buf.toString();
> }
> This method does not add commas as separators between the column names. Easily fixed by adding
> if (i<col.length-1)
> buf.append(",");
> as the last statement inside the loop.
> However, this leads to another problem:
> the type returned by IdentifierProjection.geType is the (single) type of the composite id component. The query will however return the property values of the id component without a mapping step.
--
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
14 years, 2 months
[Hibernate-JIRA] Commented: (HHH-1015) Incorrect SQL generated when one-to-many foreign key is in a discriminated subclass table
by Alexander Urmuzov (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1015?page=c... ]
Alexander Urmuzov commented on HHH-1015:
----------------------------------------
Int's not fixed in 3.5.0-CR2!
Krasimir, please attach patched jar.
> Incorrect SQL generated when one-to-many foreign key is in a discriminated subclass table
> -----------------------------------------------------------------------------------------
>
> Key: HHH-1015
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1015
> Project: Hibernate Core
> Issue Type: Bug
> Components: core
> Affects Versions: 3.1 beta 2
> Environment: Hibernate versions 3.1 beta 3 and 3.0.5
> Reporter: Steven Grimm
> Priority: Minor
> Attachments: 3.3.2.GA-HHH-1015-v1.patch, hhh-1015-version2.patch, hhh-1015.patch
>
>
> I have the following mappings describing a hierarchy of events and a class that the events refer to:
> <hibernate-mapping package="com.xyz">
> <class name="Event" table="event" discriminator-value="-1">
> <id name="Id" type="long" column="event_id"/>
> <discriminator column="event_type_id" type="integer" />
> <subclass name="EventPayer" discriminator-value="-3">
> <join table="event_payer">
> <key column="event_id" />
> <many-to-one name="payer" column="payer_id" class="Payer" />
> </join>
> <subclass name="EventPayerCreated" discriminator-value="1" />
> </subclass>
> </class>
> <class name="Payer" table="payer">
> <id name="payerId" column="payer_id" type="java.lang.Long"/>
> <set name="eventPayers" inverse="true" cascade="save-update">
> <key column="payer_id"/>
> <one-to-many class="EventPayer"/>
> </set>
> </class>
> </hibernate-mapping>
> When I fetch the Payer.eventPayers collection, Hibernate generates this SQL:
> select eventpayer0_.payer_id as payer7_1_,
> eventpayer0_.event_id as event1_1_,
> eventpayer0_.event_id as event1_5_0_,
> eventpayer0_1_.payer_id as payer2_6_0_,
> eventpayer0_.event_type_id as event2_5_0_
> from event eventpayer0_
> inner join event_payer eventpayer0_1_
> on eventpayer0_.event_id=eventpayer0_1_.event_id
> where eventpayer0_.payer_id=?
> The problem is that there is no event.payer_id column; payer_id is in the child table, not the parent. It appears that specifying a discriminated subclass in <one-to-many> is the same as specifying the superclass, or that Hibernate is ignoring the subclass's <join> element. As far as I can tell, this leaves no way to resolve bidirectional associations where one end of the association is in a discriminated subclass, which seems like a perfectly reasonable thing to want to do.
> I also tried changing <key column="payer_id"/> to <key property-ref="payer"/> in the Payer class's <set> element, but got similar behavior in the form of a "property not found" error: Hibernate is either looking in the superclass's properties rather than the subclass's or is ignoring the list of properties in the <join> element.
--
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
14 years, 2 months
[Hibernate-JIRA] Created: (HHH-2668) Caching Fails with Composite-Ids Containing Nested, Complex Entities
by Juan Osuna (JIRA)
Caching Fails with Composite-Ids Containing Nested, Complex Entities
--------------------------------------------------------------------
Key: HHH-2668
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2668
Project: Hibernate3
Issue Type: Bug
Components: caching (L2)
Affects Versions: 3.2.4.sp1
Environment: Problem is independent of environment or platform and most likely exists in prior versions.
Reporter: Juan Osuna
Attachments: hibernate-caching-fix.zip
Description of Failing Test Case Scenario
Preconditions: An entity class is mapped that uses a composite-id that contains a nested entity class. Only the composite-id class implements equals/hashcode, not the nested entity class.
Steps to Reproduce:
1. open session and fetch object using composite-id
2. open new session and fetch same object again using different instance of composite-id but with same identity
Invalid Postconditions: On second retrieve, Hibernate fails to get the object from the cache and unnecessarily reloads the object. CachKeys containing different instances of the composite-id always fail to be equal even though they have the same persistent identity.
Attachment Contents
Code fix is attached as well as a Junit test case that reproduces the problem and validates the fix. The full Hibernate suite was also executed with no impact.
Attachment contains:
New Test Method:
org.hibernate.test.cache.BaseCacheProviderTestCase.testQueryCacheComplexItem
New Test Entity Items:
org\hibernate\test\cache\ComplexItem.hbm.xml
org.hibernate.test.cache.ComplexItem
org.hibernate.test.cache.ComplexItemPK
Code Fix:
org.hibernate.cache.CacheKey (see FIX comments)
Problem and Fix Details
Hibernate generally strives to use persistent identifiers for managing object identity rather than the equals/hashcode methods implemented by entity classes. While it is good practice to implement equals/hashcode, Hibernate does not generally force users to do this.
When wrapping a composite-id object, the current implementation of CacheKey fails to recurse through nested complex entities to query for equality based on persistent identity. Instead, when the recursion algorithm hits a complex entity, it invokes equals directly on that entity rather than further recursing through the identifier object.
Notably, the recursion logic for equals is not symmetrical with the recursion logic for hashcode, which does recurse through identifier objects. So, while CacheKey never invokes hashcode on nested complex entities, it does invoke equals on these entities.
A simple fix to this inconsistency is to store the factory parameter passed to CacheKey and later pass that parameter to the overloaded method:
Type.isEqual(Object x, Object y, EntityMode entityMode, SessionFactoryImplementor factory).
This fix restores symmetry to equals and hashcode behavior. By calling this overloaded method, the thread of execution will enter EntityType. isEqual(Object x, Object y, EntityMode entityMode, SessionFactoryImplementor factory), which correctly recurses through complex identifiers.
Design Principles
Hibernate should strive to behave predictably even in scenarios where users do not follow best practices.
Hibernate should strive to be as forgiving as possible as long there is no negative consequence caused by such forgiveness.
Hibernate should behave as consistently as possible. If Hibernate does not generally rely user-implemented equals/hashcode, it is best to avoid exceptions to this rule wherever possible.
Possible Future Enhancement
Mapping composite-ids that contain complex entities can cause deep object graphs to be cached as part of CacheKey. This is unsettling because of it's potential to consume memory unnecessarily and unpredictably.
Currently, CacheKey caches the hashcode by recursing through a complex graph of identifier objects. Perhaps, it would also be possible for CacheKey to cache an object graph of identifier objects whose leaves hold primitive values. This would further add symmetry between hashcode and equals and lighten the load for caching composite-ids that hold entity classes.
Robustly supporting composite-ids that hold complex identifiers seems like a worthwhile design goal.
--
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
14 years, 2 months
[Hibernate-JIRA] Created: (HHH-4967) Mapping a class more than once using entity names causes NullPointerException in org.hibernate.ejb.event.EJB3FlushEntityEventListener
by Gunnar von der Beck (JIRA)
Mapping a class more than once using entity names causes NullPointerException in org.hibernate.ejb.event.EJB3FlushEntityEventListener
-------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-4967
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4967
Project: Hibernate Core
Issue Type: Bug
Components: entity-manager
Affects Versions: 3.3.2
Environment: Hibernate Entity Manager 3.3.2.GA, JBoss EAP 4.3, Oracle 10
Reporter: Gunnar von der Beck
Map a class more than once and use *entity names*, e.g. as follows:
{code:xml}
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping>
<!-- Mapping for multilingual texts up to 4000 characters -->
<class dynamic-insert="true" dynamic-update="true" optimistic-lock="version"
name="mypackage.MultilingualText" table="multilingualtext"
entity-name="MultilingualShort">
...
<!-- the short text -->
<property name="text" type="java.lang.String">
<column name="text" sql-type="varchar2(4000)" />
</property>
</class>
<!-- Mapping for multilingual texts holding more than 4000 characters -->
<class dynamic-insert="true" dynamic-update="true" optimistic-lock="version"
name="mypackage.MultilingualText" table="multilinguallongtext"
entity-name="MultilingualLong">
...
<!-- the long text -->
<property name="text" type="java.lang.String">
<column name="text" sql-type="clob" />
</property>
</class>
</hibernate-mapping>
{code}
Use this entity names within a list / set / map /... as follows:
{code:xml}
<class name="myClass" ...>
...
<!-- multilingual text field for up to 4000 characters -->
<set access="field" cascade="all,delete-orphan" fetch="join" lazy="false"
name="description" table="myclassdescription">
<key>
<column name="myclass_id" sql-type="varchar2(36)" />
</key>
<many-to-many unique="true" class="mypackage.MultilingualText"
entity-name="MultilingualShort">
<column name="text_id" sql-type="varchar2(36)"/>
</many-to-many>
</set>
...
</class>
{code}
When modifying such a list / set / map and calling {{entityManager.merge(<myClass>)}} you get the following exception on {{entityManager.flush()}}:
{noformat}
java.lang.NullPointerException
at org.hibernate.ejb.event.EJB3FlushEntityEventListener.copyState(EJB3FlushEntityEventListener.java:53)
at org.hibernate.ejb.event.EJB3FlushEntityEventListener.invokeInterceptor(EJB3FlushEntityEventListener.java:42)
at org.hibernate.event.def.DefaultFlushEntityEventListener.handleInterception(DefaultFlushEntityEventListener.java:308)
at org.hibernate.event.def.DefaultFlushEntityEventListener.scheduleUpdate(DefaultFlushEntityEventListener.java:248)
at org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:128)
at org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:196)
at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:76)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:26)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:304)
{noformat}
*Solution:* correct the {{org.hibernate.ejb.event.EJB3FlushEntityEventListener}} as follows:
{code:title=EJB3FlushEntityEventListener.java|borderStyle=solid}
/**
* Overrides the LifeCycle OnSave call to call the PreUpdate operation.
* <p>
* Error corrected version derived from {@code hibernate-entitymanager-3.3.2GA}.
* See method {@code copyState}: considered entity name!
*/
public class EJB3FlushEntityEventListener extends DefaultFlushEntityEventListener implements CallbackHandlerConsumer {
/**
* This class serial version UID.
*/
private static final long serialVersionUID = 1L;
private EntityCallbackHandler callbackHandler;
public void setCallbackHandler(EntityCallbackHandler callbackHandler) {
this.callbackHandler = callbackHandler;
}
public EJB3FlushEntityEventListener() {
super();
}
public EJB3FlushEntityEventListener(EntityCallbackHandler callbackHandler) {
super();
this.callbackHandler = callbackHandler;
}
@Override
protected boolean invokeInterceptor(
SessionImplementor session, Object entity, EntityEntry entry, Object[] values, EntityPersister persister
) {
boolean isDirty = false;
if ( entry.getStatus() != Status.DELETED ) {
if ( callbackHandler.preUpdate( entity ) ) {
isDirty = copyState( entity, entry.getEntityName() ,persister.getPropertyTypes(), values, session.getFactory() );
}
}
return super.invokeInterceptor( session, entity, entry, values, persister ) || isDirty;
}
/**
* copy the entity state into the state array and return true if the state has changed
*/
// modified parameter list: ++entityName
private boolean copyState(Object entity, String entityName, Type[] types, Object[] state, SessionFactory sf) {
// modified: consider entity names when resolving metadata!
ClassMetadata metadata =
(entityName != null ? sf.getClassMetadata(entityName) : sf.getClassMetadata(entity.getClass()));
Object[] newState = metadata.getPropertyValues( entity, EntityMode.POJO );
int size = newState.length;
boolean isDirty = false;
for ( int index = 0; index < size ; index++ ) {
if ( !types[index].isEqual( state[index], newState[index], EntityMode.POJO ) ) {
isDirty = true;
state[index] = newState[index];
}
}
return isDirty;
}
}
{code}
The significant change of the code is to consider the entity name when looking up {{ClassMetadata}} in method {{copyState()}}:
{code}
ClassMetadata metadata = (entityName != null ? sf.getClassMetadata(entityName) : sf.getClassMetadata(entity.getClass()));
{code}
--
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
14 years, 2 months
[Hibernate-JIRA] Created: (HBX-1160) Hibernate-tools don't compile with hibernate-core 3.5
by André Lehmann (JIRA)
Hibernate-tools don't compile with hibernate-core 3.5
-----------------------------------------------------
Key: HBX-1160
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1160
Project: Hibernate Tools
Issue Type: Patch
Components: annotations (obsolete), ant, consoleconfiguration, datagen, doc, eclipse, hbm2doc, hbm2java, hbm2seam, hbmlint, middlegenplugin, reverse-engineer, visualizations
Environment: hibernate-core 3.5
Reporter: André Lehmann
Attachments: hibernate-tools3.5.patch
The lastest code of Hibernate-tools don't more compile with hibernate-core trunk.
The attached patch allow just compile HBX with hibernate-core trunk.
--
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
14 years, 2 months
[Hibernate-JIRA] Commented: (HBX-548) FAQ. DESCSTAT=YES required for DB2 on z/OS
by Igor Regis da Silva Simões (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-548?page=co... ]
Igor Regis da Silva Simões commented on HBX-548:
------------------------------------------------
I tested the DB2OS390MetaDataDialect and it works with DB2 9 on OS/390.
Could someone commit this new Dialect into SVN repository? As the hibernate tools documentation at chapter 5 item 5.4 "Custom Database Metadata" the users are invited to contribute with new Dialects. This new dialect is necessary because JDBCMetaDataDialect don't process correctly the DB2 metadata, even with DECSTAT=YES, because the columns names are not like the ones that are expected.
> 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
> Issue Type: Improvement
> Components: reverse-engineer
> Affects Versions: 2.1, 3.0alpha, 3.0alpha2, 3.0alpha3, 3.0alpha4, 3.0beta1, 3.0beta2, 3.0beta3, 3.1alpha5, 3.1beta1, 3.1beta2, 3.1beta3, 3.1beta4, 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
14 years, 2 months