[Hibernate-JIRA] Created: (HHH-7311) NullPointerException if TenantConnectionProvider class does not exist
by Oriel Maute (JIRA)
NullPointerException if TenantConnectionProvider class does not exist
---------------------------------------------------------------------
Key: HHH-7311
URL: https://hibernate.onjira.com/browse/HHH-7311
Project: Hibernate ORM
Issue Type: Bug
Components: core
Affects Versions: 4.1.2
Environment: Hibernate 4.1.2, using JPA
Reporter: Oriel Maute
Priority: Trivial
Im using schema based multi tenancy. If i define a "hibernate.multi_tenant_connection_provider" which classfile does not exist in persistence.xml, a NullPointerException come up:
<property name="hibernate.multi_tenant_connection_provider" value="com.xoricon.framework.server.jpa.tenant.TenantConnectionProvider"/>
Class "com.xoricon.framework.server.jpa.tenant.TenantConnectionProvider" does not exist on classpath.
Result:
1) testTreeOrder(com.xoricon.persistence.bo.multitenancy.test.SchemaBasedMultiTenancyTest)java.lang.NullPointerException
at org.hibernate.engine.jdbc.internal.JdbcServicesImpl$MultiTenantConnectionProviderJdbcConnectionAccess.obtainConnection(JdbcServicesImpl.java:260)
at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:117)
at org.hibernate.service.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:75)
at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:71)
at org.hibernate.cfg.Configuration.buildSettingsInternal(Configuration.java:2274)
at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2270)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1739)
at org.hibernate.ejb.EntityManagerFactoryImpl.<init>(EntityManagerFactoryImpl.java:93)
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:905)
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:890)
at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:57)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:48)
at com.xoricon.persistence.bo.test.AbstractTestCase.getEntityManagerFactory(AbstractTestCase.java:45)
at com.xoricon.persistence.bo.multitenancy.test.SchemaBasedMultiTenancyTest.testTreeOrder(SchemaBasedMultiTenancyTest.java:42)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at com.xoricon.persistence.bo.multitenancy.test.SchemaBasedMultiTenancyTest.main(SchemaBasedMultiTenancyTest.java:53)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[Hibernate-JIRA] Created: (HHH-7310) Resolution of types registered in type registry does not work properly for Properties of @Embeddable types
by Chris Pheby (JIRA)
Resolution of types registered in type registry does not work properly for Properties of @Embeddable types
----------------------------------------------------------------------------------------------------------
Key: HHH-7310
URL: https://hibernate.onjira.com/browse/HHH-7310
Project: Hibernate ORM
Issue Type: Bug
Components: core
Affects Versions: 4.1.3
Environment: Any
Reporter: Chris Pheby
The new type registry capability in Hibernate 4 and above is really useful. I have implemented an integrator that autoregisters some types, however what I have found is that whilst this works perfectly, the registered types are not being resolved correctly when they are used within @Embeddable classes.
This is easily reproduced: for example, using Jadira Usertype (usertype.sourceforge.net), setting the system property to autoregister types and updating a test class to use @Embeddable triggers the problem.
The problem occurs because the types are first initialised during a call to Configuration validate(). This occurs before any integrators are invoked and consequently types that will be mapped by the integrator at that time are mapped to either their existing basic type or Serializable. They are only remapped on future calls to getType on the type (such as within heuristic type).
The resolution of the issue lies in removing the caching from Component because in the case of Component types these are not remapped on repeated calls to getType.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[Hibernate-JIRA] Created: (HHH-5929) PooledLoOptimizer in conjunction with SequenceStyleGenerator is not thread-safe
by Robin Sander (JIRA)
PooledLoOptimizer in conjunction with SequenceStyleGenerator is not thread-safe
-------------------------------------------------------------------------------
Key: HHH-5929
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5929
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.1
Environment: Hibernate 3.6.1, Java 6, Mac OS 10.6.6
Reporter: Robin Sander
The generate method of the PooledLoOptimizer introduced in 3.6.1 is not synchronized in difference to the one in PooledOptimizer and in other Optimizer implementations. The problem is that some IdentifierGenerator implementations have themselve a synchronized generate method (like SequenceHiLoGenerator e.g.) and some don't, like the new SequenceStyleGenerator.
According to the javadoc IdentifierGenerator implementations have to be thread-safe. Now I don't know if there is any agreement among the developers whether this thread-safety is to be achieved in the IdentifierGenerator itself or in the Optimizer most of them delegate to but what I know is that SequenceStyleGenerator in conjunction with PooledLoOptimizer is not thread-safe because neither of them guards against concurrent access in any way.
--
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
11 years, 11 months
[Hibernate-JIRA] Created: (HHH-6707) One-to-One mapping with foreign key in target table and foreign key being the primary key fails with Oracle
by Florian Rampp (JIRA)
One-to-One mapping with foreign key in target table and foreign key being the primary key fails with Oracle
-----------------------------------------------------------------------------------------------------------
Key: HHH-6707
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6707
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.6
Environment: Oracle 11g, Oracle JDBC 11.2.0.1.0
Reporter: Florian Rampp
Attachments: bugreports-hibernate-oracleUniquePk-1.0-SNAPSHOT-src.zip
When mapping a one-to-one parent/child relationship with the foreign key being in the child table and forming its primary key, in addition to the primary key definition, a unique constraint is generated (due to the one-to-one inverse mapping). A unique constraint and a primary key definition on the same column is not accepted by Oracle. The error is "ORA-02261: such unique or primary key already exists in the table" when creating the schema.
The key entities:
{code:java}
@Entity
public class Parent {
@Id
Long id;
@OneToOne(cascade = CascadeType.ALL, orphanRemoval = true, mappedBy = "parent")
Child child;
}
@Entity
public class Child implements Serializable {
@Id
@OneToOne(optional = false)
private Parent parent;
}
{code}
The resulting DDL is:
{code:sql}
create table Child (
parent_id number(19,0) not null,
primary key (parent_id),
unique (parent_id)
)
{code}
This issue is similar to https://hibernate.onjira.com/browse/HBX-978. But I refiled it here since I consider it to be a bug in Hibernate core. Also, I provided a test case that can be used for regression tests. It needs to be executed with the arguments {{-Dhibernate.connection.username=<USERNAME> -Dhibernate.connection.password=<PASSWORD> -Dhibernate.connection.url=<JDBC_URL>}}.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[Hibernate-JIRA] Created: (HHH-2158) incorrect hql query on one-to-one with property-ref
by Sebastien Cesbron (JIRA)
incorrect hql query on one-to-one with property-ref
----------------------------------------------------
Key: HHH-2158
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2158
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.ga
Environment: hibernate 3.2.0.ga with firebird 1.5.3 and jaybird 1.5.5 driver on windows XP
Reporter: Sebastien Cesbron
Attachments: testhib.zip
I have a one-to-one relationship with property-ref between Master and Slave2.
I want to find all Master instances that have a null Slave2 instance associated.
To do so my query is
select master from Master master where master.slave2 is null
The sql generated is
select master0_.oid as oid0_, master0_.libelle as libelle0_ from Master master0_ where master0_.oid is null
which seems incorrect. It checks here Master instances with null id (config files are listed below).
If I do my query like this
select master from Master master where master.slave2.oid is null
the generated sql is ok :
select master0_.oid as oid0_, master0_.libelle as libelle0_ from Master master0_, Slave2 slave2x1_ where master0_.oid=slave2x1_.myMaster and (slave2x1_.oid is null)
I have attached a small eclipse project that reproduces the problem
This problem may-be related to the one I have submitted as issue HHH-1849
--
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
11 years, 11 months
[Hibernate-JIRA] Created: (HHH-7019) SQLServer2005Dialect, SQLServer2008Dialect issues with subqueries
by Matthew Brock (JIRA)
SQLServer2005Dialect, SQLServer2008Dialect issues with subqueries
-----------------------------------------------------------------
Key: HHH-7019
URL: https://hibernate.onjira.com/browse/HHH-7019
Project: Hibernate ORM
Issue Type: Bug
Components: core
Affects Versions: 3.6.9
Environment: Microsoft SQLServer 2005, Microsoft SQLServer 2008
Reporter: Matthew Brock
Priority: Minor
Attachments: SQLServer2005Dialect.java
There are a few bugs with the way the SQLServer2005Dialect is generating the pseudo-limit wrapper (ROW_NUMBER() OVER).
---
#1: Indeterminate return results when strings are returned from subqueries
line 116: StringBuilder sb = new StringBuilder(querySqlString.trim().toLowerCase());
Take the following example:
@Formula("(select case when name = 'Smith' then 'Neo' else name end)")
public String getName() { ... }
toLowerCase() will lose any capitalization in subselects and break the CASE statement.
FIX: Move toLowerCase() test down the chain, don't modify original query.
---
#2: GenericJDBCException whenever subqueries are part of a SELECT
line 118: int orderByIndex = sb.indexOf("order by");
line 147: int distinctIndex = sql.indexOf(DISTINCT);
line 163: sql.substring(sql.indexOf(SELECT) + SELECT.length(), sql.indexOf(FROM));
This issue stems from using indexOf() to search the original SQL for specific keywords that could possibly exist in subqueries (@Formulas tend to be the biggest offenders).
Example:
@Formula("(select distinct(a.zip) from address a where a.person_id = id")
public String getZip() { ... }
The DISTINCT and FROM keywords will break the query generation.
FIX: Since all @Formulas are wrapped in parenthesis when they are aliased, I simply count the number of open parenthesis when doing an indexOf() search on SQL statements and ignore any results if the number of open parenthesis doesn't equal 0.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 12 months
[Hibernate-JIRA] Created: (HHH-7116) Ordered Criteria query that joins with an ordered mapped collection results in incorrect overall ordering
by Tommy Knowlton (JIRA)
Ordered Criteria query that joins with an ordered mapped collection results in incorrect overall ordering
---------------------------------------------------------------------------------------------------------
Key: HHH-7116
URL: https://hibernate.onjira.com/browse/HHH-7116
Project: Hibernate ORM
Issue Type: Bug
Components: core, query-criteria
Affects Versions: 4.1.0, 3.6.10
Reporter: Tommy Knowlton
A criteria query for Items that joins (with sub-criteria or alias) Bids, where mapped Bids collection is ordered [e.g., @OrderBy("bidamount desc")] and where the criteria query is ordered by Item descriptions [c.addOrder(Order.asc("description"))] will result in generated SQL having incorrect overall ordering: the ordering specified by the mapped association is output first, followed by the ordering specified on the criteria. Using the example, it ends up looking like "order by bid3_.AMOUNT desc, this_.DESCRIPTION asc".
There are actually two issues here. The first is that the association's ordering is overriding the criteria's ordering. Instead of having Items ordered alphabetically by description, and each Item's bids ordered by decreasing bid amounts, we have Items ordered from those having highest bids, down to those having lower bids, with alike bids ordered by description, alphabetically. It ends up being a simple matter to fix this issue in the "JoinWalker" base class.
The second issue is that in cases where a mapped association has an ordering specified, there is really an implied ordering by primary (or natural) key of the owning entity that has higher precedence than the association ordering. In the Items/Bids example, think about what happens to the criteria query if two items happen to have the same description text, and each has many bids: the result rows will be interleaved. It probably ends up being an implementation detail of the result transformer whether that matters or not, but I think that a "more correct" or at least less-surprising behavior would be for the "JoinWalker" to output orderby subclauses in such a way as to make the implied ordering (that keeps owning entities together in the resultset) explicit.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 12 months
[Hibernate-JIRA] Created: (HHH-6829) PooledLoOptimizer.generate() should be synchronized
by Manuel Dominguez Sarmiento (JIRA)
PooledLoOptimizer.generate() should be synchronized
---------------------------------------------------
Key: HHH-6829
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6829
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.8
Reporter: Manuel Dominguez Sarmiento
Priority: Critical
We recently switched to this ID generation optimizer in our highly concurrent production platform, and began getting random id / PK collision errors very often.
Checking the code, it's pretty obvious that the problem lies with generate() not being synchronized. All other optimizers (PooledOptimizer, LegacyHiLoAlgorithmOptimizer, HiLoOptimizer, etc.) are synchronized - PooledLoOptimizer should be as well.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 12 months
[Hibernate-JIRA] Created: (HBX-948) org.hibernate.connection.DriverManagerConnectionProvider - problem closing pooled connection
by Sathish P (JIRA)
org.hibernate.connection.DriverManagerConnectionProvider - problem closing pooled connection
--------------------------------------------------------------------------------------------
Key: HBX-948
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-948
Project: Hibernate Tools
Issue Type: Bug
Components: consoleconfiguration
Affects Versions: 3.1.beta5
Environment: Eclipse
Reporter: Sathish P
WARN Finalizer org.hibernate.connection.DriverManagerConnectionProvider - problem closing pooled connection
java.sql.SQLException: Io exception: Socket closed
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:146)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:255)
at oracle.jdbc.driver.T4CConnection.logoff(T4CConnection.java:481)
at oracle.jdbc.driver.PhysicalConnection.close(PhysicalConnection.java:1203)
at org.hibernate.connection.DriverManagerConnectionProvider.close(DriverManagerConnectionProvider.java:152)
at org.hibernate.connection.DriverManagerConnectionProvider.finalize(DriverManagerConnectionProvider.java:142)
at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
at java.lang.ref.Finalizer.runFinalizer(Unknown Source)
at java.lang.ref.Finalizer.access$100(Unknown Source)
at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)
--
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
11 years, 12 months