[Hibernate-JIRA] Created: (HBX-978) unique=true attribute of primary key in generated class prevents the schema to be regenerated
by Ali Sadik Kumlali (JIRA)
unique=true attribute of primary key in generated class prevents the schema to be regenerated
---------------------------------------------------------------------------------------------
Key: HBX-978
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-978
Project: Hibernate Tools
Issue Type: Bug
Environment: OS: Windows Vista 6.0,x86
Database: Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
Java VM: Java HotSpot(TM) Server VM 1.5.0_11-b03,Sun Microsystems Inc.
Eclipse Europa: Version: 3.3.0 Build id: I20070621-1340
HibernateTools-3.2.0.beta10
Reporter: Ali Sadik Kumlali
Priority: Minor
Hi,
When I reverse engineer against Oracle, unique=true attribute is added to @Column annotation of primary key column. But, when I generate schema from these generated files, Oracle throws "ORA-02261: such unique or primary key already exists in the table" error.
I first ran into this situation while trying Seam and posted the problem to Seam's forum: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=116478. After I got the response, decided to try it without Seam. Then, downloaded the latest HibernateTools & Eclipse Europa and reverse engineered the schema. I saw that generated classes have unique=true attribute which clearly showed that the problem was related with HibernateTools, not with Seam.
Here is the DDL of the table against which I made my test:
CREATE TABLE PEOPLE ("ID" NUMBER NOT NULL, "SURNAME" VARCHAR2(50 BYTE), "NAME" VARCHAR2(25 BYTE), CONSTRAINT "PEOPLE_PK" PRIMARY KEY ("ID"));
Regards,
Ali Sadik Kumlali
--
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, 6 months
[Hibernate-JIRA] Created: (HHH-6639) Error using dynamic-component with JPA
by Wölfle (JIRA)
Error using dynamic-component with JPA
--------------------------------------
Key: HHH-6639
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6639
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.6.7
Environment: MySQL 5.0.1, Java 1.6.0_26
Reporter: Wölfle
Attachments: testJPA.tar.gz
Hi,
there seems to be a bug when using dynamic-components and an EntityManager.
When using hibernate directly, everything works fine. If using the EntityManager, the following exception is thrown, because for the dynamic attributes no members in the Entity class exist (which is the intention of dynamic-attributes, as far as I understood them).
Exception in thread "main" java.lang.IllegalArgumentException: Cannot determine java-type from given member [null]
at org.hibernate.ejb.metamodel.AttributeFactory$BaseAttributeMetadata.<init>(AttributeFactory.java:608)
at org.hibernate.ejb.metamodel.AttributeFactory$SingularAttributeMetadataImpl.<init>(AttributeFactory.java:696)
at org.hibernate.ejb.metamodel.AttributeFactory$SingularAttributeMetadataImpl.<init>(AttributeFactory.java:686)
at org.hibernate.ejb.metamodel.AttributeFactory.determineAttributeMetadata(AttributeFactory.java:559)
at org.hibernate.ejb.metamodel.AttributeFactory.buildAttribute(AttributeFactory.java:93)
at org.hibernate.ejb.metamodel.AttributeFactory.getMetaModelType(AttributeFactory.java:225)
at org.hibernate.ejb.metamodel.AttributeFactory.buildAttribute(AttributeFactory.java:102)
at org.hibernate.ejb.metamodel.MetadataContext.wrapUp(MetadataContext.java:187)
at org.hibernate.ejb.metamodel.MetamodelImpl.buildMetamodel(MetamodelImpl.java:66)
at org.hibernate.ejb.EntityManagerFactoryImpl.<init>(EntityManagerFactoryImpl.java:84)
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:906)
at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:57)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:48)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:32)
at test.Test.main(Test.java:24)
Attached is a tar.tz file with a sample hibernate project and a junit test that reproduces the problem.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[Hibernate-JIRA] Created: (HHH-6280) JPA criteria API don't bind numeric field
by gwa (JIRA)
JPA criteria API don't bind numeric field
-----------------------------------------
Key: HHH-6280
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6280
Project: Hibernate Core
Issue Type: Improvement
Components: entity-manager
Affects Versions: 3.6.4, 3.6.3, 3.6.2, 3.6.1, 3.6.0, 3.6.0.CR2, 3.6.0.CR1, 3.5.6, 3.6.0.Beta4, 3.6.0.Beta3, 3.5.5, 3.6.0.Beta2, 3.6.0.Beta1, 3.5.4, 3.5.3, 3.5.2, 3.5.1, 3.5.0-Final, 3.5.0-CR-2, 3.5.0-CR-1, 3.5.0-Beta-4, 3.5.0-Beta-3, 3.5.0-Beta-2, 3.5.0.Beta-1
Reporter: gwa
When you use JPA criteria API, the numeric value are not binded but are directly set in the SQL instead.
eq: you have a generated SQL like:
select ... from ... where age=12;
instead of
select ... from ... where age=?;
With '12' as parameter.
when you test the following code:
{code:java}
@Entity
public class User {
@Id
private int id;
private int age;
...
}
{code}
{code:java}
CriteriaBuilder builder=em.getCriteriaBuilder();
CriteriaQuery<User> query=builder.createQuery(User.class);
Root<User> root=query.from(User.class);
query.select(root).where(builder.equal(root.get("age"),12));
em.createQuery(query).getResultList();
{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
13 years, 6 months
[Hibernate-JIRA] Created: (HHH-5798) Is it really necessary to explicitly specifiy discriminatorValue for abstract classes?
by Oleksandr Alesinskyy (JIRA)
Is it really necessary to explicitly specifiy discriminatorValue for abstract classes?
--------------------------------------------------------------------------------------
Key: HHH-5798
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5798
Project: Hibernate Core
Issue Type: Improvement
Components: entity-manager
Affects Versions: 3.6.0
Reporter: Oleksandr Alesinskyy
At the time being if the SINGLE_TABLE inheritance strategy is used, the discriminator type is set to char and some abstract classes in the hierarchy do not have an explicit discriminator value specified the following error occurs:
{quote}
Caused by: org.hibernate.AnnotationException: Using default @DiscriminatorValue for a discriminator of type CHAR is not safe
at org.hibernate.cfg.annotations.EntityBinder.bindDiscriminatorValue(EntityBinder.java:373)
at org.hibernate.cfg.annotations.EntityBinder.bindEntity(EntityBinder.java:200)
at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:586)
at org.hibernate.cfg.Configuration$MetadataSourceQueue.processAnnotatedClassesQueue(Configuration.java:3977)
at org.hibernate.cfg.Configuration$MetadataSourceQueue.processMetadata(Configuration.java:3931)
at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1368)
at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1345)
at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1477)
at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:193)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:1096)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:685)
at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:73)
{quote}
At the same time it is clear that no one row in the corresponding table may represent the abstract class, so it is absolutely safe to completely ignore abstract classes when decision is made which class is represented by a row.
--
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, 6 months
[Hibernate-JIRA] Created: (HHH-6066) Postgresql can not work with @Lob type
by Steve Ni (JIRA)
Postgresql can not work with @Lob type
--------------------------------------
Key: HHH-6066
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6066
Project: Hibernate Core
Issue Type: Bug
Components: annotations
Affects Versions: 3.6.1
Environment: Postgresql 8.x and JDBC driver 9.0-801.jdbc4
Reporter: Steve Ni
My application needs compatible with some major database such as Oracle, Mysql and Postgresql. I also use hibernatetool ant task to generate DDL. I use @Type(type="text") for string. Before 3.5 version, everything is OK. However, after 3.5 Oracel uses long instead clob type. As Long is deprecated type and the Oracle JDBC driver also has bug to read Long type with hibernate (Stream closed exception). So I try to use @Lob replaces @Type(type=text). The problem is this annotation doesn't work with postgresql.
Regarding to this issue, I did some research. The better fix could be Oracle use clob instead of Long. There is not good reason use deprecated type...
Here is exception:
org.springframework.dao.DataIntegrityViolationException: could not load an entity: [com.edgenius.core.model.Configuration#7]; nested exception is org.hibernate.exception.DataException: could not load an entity: [com.edgenius.core.model.Configuration#7]
at org.springframework.orm.hibernate3.SessionFactoryUtils.convertHibernateAccessException(SessionFactoryUtils.java:639)
at org.springframework.orm.hibernate3.HibernateAccessor.convertHibernateAccessException(HibernateAccessor.java:412)
at org.springframework.orm.hibernate3.HibernateTemplate.doExecute(HibernateTemplate.java:424)
at org.springframework.orm.hibernate3.HibernateTemplate.executeWithNativeSession(HibernateTemplate.java:374)
at org.springframework.orm.hibernate3.HibernateTemplate.find(HibernateTemplate.java:921)
at org.springframework.orm.hibernate3.HibernateTemplate.find(HibernateTemplate.java:917)
at com.edgenius.core.dao.hibernate.UserDAOHibernate.getUserByName(UserDAOHibernate.java:145)
at com.edgenius.core.dao.hibernate.UserDAOHibernate.loadUserByUsername(UserDAOHibernate.java:192)
at com.edgenius.wiki.security.acegi.TokenBasedRememberMeServices.processAutoLoginCookie(TokenBasedRememberMeServices.java:67)
at org.springframework.security.ui.rememberme.AbstractRememberMeServices.autoLogin(AbstractRememberMeServices.java:85)
at org.springframework.security.ui.rememberme.RememberMeProcessingFilter.doFilterHttp(RememberMeProcessingFilter.java:74)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
at org.springframework.security.wrapper.SecurityContextHolderAwareRequestFilter.doFilterHttp(SecurityContextHolderAwareRequestFilter.java:91)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
at org.springframework.security.ui.AbstractProcessingFilter.doFilterHttp(AbstractProcessingFilter.java:277)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
at org.springframework.security.ui.logout.LogoutFilter.doFilterHttp(LogoutFilter.java:89)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
at com.edgenius.wiki.security.acegi.CaptchaValidationProcessingFilter.doFilter(CaptchaValidationProcessingFilter.java:76)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
at org.springframework.security.context.HttpSessionContextIntegrationFilter.doFilterHttp(HttpSessionContextIntegrationFilter.java:235)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
at org.springframework.security.util.FilterChainProxy.doFilter(FilterChainProxy.java:175)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:236)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.edgenius.core.webapp.filter.LocaleFilter.doFilterInternal(LocaleFilter.java:147)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:198)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.edgenius.wiki.webapp.filter.InstallFilter.doFilterInternal(InstallFilter.java:50)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.hibernate.exception.DataException: could not load an entity: [com.edgenius.core.model.Configuration#7]
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:102)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
at org.hibernate.loader.Loader.loadEntity(Loader.java:2041)
at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:86)
at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:76)
at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3293)
at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:496)
at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:477)
at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:227)
at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:285)
at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:152)
at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:1090)
at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:1038)
at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:630)
at org.hibernate.type.EntityType.resolve(EntityType.java:438)
at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:139)
at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:982)
at org.hibernate.loader.Loader.doQuery(Loader.java:857)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:274)
at org.hibernate.loader.Loader.doList(Loader.java:2533)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2276)
at org.hibernate.loader.Loader.list(Loader.java:2271)
at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:452)
at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:363)
at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:196)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1268)
at org.hibernate.impl.QueryImpl.list(QueryImpl.java:102)
at org.springframework.orm.hibernate3.HibernateTemplate$30.doInHibernate(HibernateTemplate.java:930)
at org.springframework.orm.hibernate3.HibernateTemplate.doExecute(HibernateTemplate.java:419)
... 51 more
Caused by: org.postgresql.util.PSQLException: Bad value for type long
at org.postgresql.jdbc2.AbstractJdbc2ResultSet.toLong(AbstractJdbc2ResultSet.java:2796)
at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getLong(AbstractJdbc2ResultSet.java:2019)
at org.postgresql.jdbc4.Jdbc4ResultSet.getClob(Jdbc4ResultSet.java:43)
at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getClob(AbstractJdbc2ResultSet.java:384)
at org.apache.commons.dbcp.DelegatingResultSet.getClob(DelegatingResultSet.java:568)
at org.apache.commons.dbcp.DelegatingResultSet.getClob(DelegatingResultSet.java:568)
at org.hibernate.type.descriptor.sql.ClobTypeDescriptor$4.doExtract(ClobTypeDescriptor.java:104)
at org.hibernate.type.descriptor.sql.BasicExtractor.extract(BasicExtractor.java:64)
at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:253)
at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:249)
at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:229)
at org.hibernate.type.AbstractStandardBasicType.hydrate(AbstractStandardBasicType.java:330)
at org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2283)
at org.hibernate.loader.Loader.loadFromResultSet(Loader.java:1527)
at org.hibernate.loader.Loader.instanceNotYetLoaded(Loader.java:1455)
at org.hibernate.loader.Loader.getRow(Loader.java:1355)
at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:611)
at org.hibernate.loader.Loader.doQuery(Loader.java:829)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:274)
at org.hibernate.loader.Loader.loadEntity(Loader.java:2037)
--
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, 6 months
[Hibernate-JIRA] Created: (HHH-5585) SubDialect of PostgreSQLDialect to support (@Lob + byte[]) combination
by Justin Sands (JIRA)
SubDialect of PostgreSQLDialect to support (@Lob + byte[]) combination
----------------------------------------------------------------------
Key: HHH-5585
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5585
Project: Hibernate Core
Issue Type: Patch
Environment: 3.6.0.CR1, postgresql
Reporter: Justin Sands
Attachments: CustomPostgreSQLDialect.zip
>From hibernate 3.5 to 3.6 the annotation combination @Lob + byte[] does not on postgresql work due to idiosyncrasies in the postgresql JDBC driver.
To support this combination, the following dialect variant can be used along with a basic-type override, provided that the application consistently uses the same annotation style (@Lob + byte[]). A similar approach could be used to support using the OID blob type which postgresql provides, although this patch does not address it.
The user must register the basic type override MateralizedVarBinaryBlobType at boot time.
I am unsure exactly where in the distribution this would fit so I have kept it in one package (org.hibernate.dialect.variant).
I have test cases which I could detach from my current project, if the maintainers think this patch is worth including.
--
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, 6 months
[Hibernate-JIRA] Created: (HHH-6433) PostCommitListeners are called during rollback
by Shawn Clowater (JIRA)
PostCommitListeners are called during rollback
----------------------------------------------
Key: HHH-6433
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6433
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.2
Environment: JDK 1.6u25, Win7, Oracle10
Reporter: Shawn Clowater
EntityActions that are registered as part of transaction completion are still called when the transaction didn't succeed.
As an example, the DeleteEntityAction
{code}
public void doAfterTransactionCompletion(boolean success, SessionImplementor session) throws HibernateException {
if ( getPersister().hasCache() ) {
final CacheKey ck = new CacheKey(
getId(),
getPersister().getIdentifierType(),
getPersister().getRootEntityName(),
getSession().getEntityMode(),
getSession().getFactory()
);
getPersister().getCacheAccessStrategy().unlockItem( ck, lock );
}
postCommitDelete();
}
{code}
The success is false in the event of a rollback so it doesn't update the cache but it still calls the postCommitDelete which triggers the postCommitDelete listeners. I would think this should only occur in the event that the transaction was actually committed.
To add insult to injury the ActionQueue will also add failed actions to the after transaction completion queue and invalidate the query spaces.
{code}
public void execute(Executable executable) {
try {
executable.execute();
}
finally {
registerCleanupActions( executable );
}
}
private void registerCleanupActions(Executable executable) {
beforeTransactionProcesses.register( executable.getBeforeTransactionCompletionProcess() );
if ( session.getFactory().getSettings().isQueryCacheEnabled() ) {
final String[] spaces = (String[]) executable.getPropertySpaces();
afterTransactionProcesses.addSpacesToInvalidate( spaces );
session.getFactory().getUpdateTimestampsCache().preinvalidate( spaces );
}
afterTransactionProcesses.register( executable.getAfterTransactionCompletionProcess() );
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months