2016-01-18 1 views
0

Je suis en train de mettre à jour une application depuis Hibernate 3.6.10.Final vers la version 5.0.7.Final Le problème principal que j'ai en ce moment est que quand le dialecte Oracle générait une requête assez rapide comme ceci:Traducteur Hibernate 5 HQL pour Oracle Spatial

SELECT * FROM MY_TABLE 
WHERE SDO_RELATE(geom,SDO_GEOMETRY(?,4326),'mask=INSIDE+COVEREDBY') ='TRUE' 

maintenant, il va générer quelque chose de terriblement lent:

SELECT * FROM MY_TABLE 
WHERE MDSYS.OGC_WITHIN(MDSYS.ST_GEOMETRY.FROM_SDO_GEOM(geom),MDSYS.ST_GEOMETRY.FROM_SDO_GEOM(?))=1 

celui-ci ne sera pas terminé à temps et augmenter un délai d'attente de transaction:

JTA transaction unexpectedly rolled back (maybe due to a timeout 

Je ne peux que penser qu'il y a quelque chose qui ne va pas avec la classe de dialecte utilisée pour traduire HQL en un SQL spatial Oracle performant.

Ma configuration est la suivante.

pom.xml:

<dependency> 
     <groupId>org.hibernate</groupId> 
     <artifactId>hibernate-core</artifactId> 
     <version>5.0.7.Final</version> 
    </dependency> 
    <dependency> 
     <groupId>org.hibernate</groupId> 
     <artifactId>hibernate-entitymanager</artifactId> 
     <version>5.0.7.Final</version> 
    </dependency> 
    <dependency> 
     <groupId>org.hibernate</groupId> 
     <artifactId>hibernate-spatial</artifactId> 
     <version>5.0.7.Final</version> 
    </dependency> 

Mon persistence.xml, où je configure Atomikos (4.0.0M4) en tant que gestionnaire de transactions.

<persistence-unit name="pers_unit_name" transaction-type="JTA"> 
<provider>org.hibernate.ejb.HibernatePersistence</provider> 
<jta-data-source>jta_data_source_name</jta-data-source> 
<mapping-file>oracle.hbm.xml</mapping-file> 
<class>...</class> 
<properties> 
     <property name="hibernate.dialect" value="org.hibernate.spatial.dialect.oracle.OracleSpatial10gDialect" /> 
     <property name="hibernate.spatial.dialect" value="org.hibernate.spatial.dialect.oracle.OracleSpatial10gDialect" /> 
     <property name="hibernate.spatial.connection_finder" value="org.geolatte.geom.codec.db.oracle.DefaultConnectionFinder" /> 
     <property name="hibernate.connection.autocommit" value="false" /> 
     <property name="hibernate.transaction.manager_lookup_class" value="com.atomikos.icatch.jta.hibernate4.TransactionManagerLookup" /> 
     <property name="transaction.factory_class" 
      value="org.hibernate.transaction.JTATransactionFactory" />   
     <property name="hibernate.transaction.jta.platform" value="com.atomikos.icatch.jta.hibernate4.AtomikosPlatform"/> 
     <property name="hibernate.transaction.coordinator_class" value="jta"/> 
     <property name="hibernate.cache.provider_class" value="org.hibernate.cache.NoCacheProvider" /> 
    </properties> 
</persistence-unit> 

Quand je debug HQLQueryPlan je vois le traducteur de requête qu'il utilise est interne:

org.hibernate.hql.internal.ast.QueryTranslatorImpl 

Je ne sais pas si cela est bien ou mal, ou comment cela pourrait être configuré pour générer la requête droite .

Cette application est en cours d'exécution sur Tomcat 8.

Le POJO utilisé avec Hibernate pour mapper l'entité contient cet attribut geom qui est défini comme:

@Column(name = "geom", columnDefinition="Geometry", nullable = true) 
protected Geometry geom; 

Répondre

2

Il semble que la mise en OGC_STRICT=false a fait l'affaire. Cela indique à Hibernate d'utiliser directement les propres fonctions spatiales d'Oracle, au lieu d'utiliser les fonctions compatibles Open Geospatial, comme nous pouvons le voir dans la documentation OGC compliance setting. En fait, nous l'avions déjà configuré dans le fichier org.hibernatespatial.oracle.OracleSpatial10gDialect.properties, mais parce que, après la mise à niveau, il devrait porter le nom org.hibernate.spatial.dialect.oracle.OracleSpatial10gDialect.properties, cela ne fonctionnerait pas pour nous.