[Hibernate-JIRA] Created: (HHH-3930) one-to-one causes redundant select query
by Martijn Dashorst (JIRA)
one-to-one causes redundant select query
----------------------------------------
Key: HHH-3930
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3930
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1
Reporter: Martijn Dashorst
@Entity
public class Address {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private Long id;
@OneToOne(mappedBy = "address")
private Customer customer;
}
@Entity
public class Customer {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private Long id;
@OneToOne(fetch = FetchType.EAGER, cascade = CascadeType.ALL)
private Address address = new Address();
public Long getId() {
return id;
}
public Address getAddress() {
return address;
}
}
This mapping causes 2 instead of the expected 1 query to retrieve a Customer and its Address from the db:
select * from Customer customer0_ left outer join Address address1_ on customer0_.address_id=address1_.id where customer0_.id=?
select * from Customer customer0_ left outer join Address address1_ on customer0_.address_id=address1_.id where customer0_.address_id=?
Changing the mapping to a LAZY fetch type:
@OneToOne(fetch = FetchType.LAZY, cascade = CascadeType.ALL)
private Address address = new Address();
Causes 3 select queries instead of the expected 2 queries to retrieve a Customer (and its Address) from the db:
select * from Customer customer0_ where customer0_.id=?
select * from Address address0_ left outer join Customer customer1_ on address0_.id=customer1_.address_id where address0_.id=?
select * from Customer customer0_ where customer0_.address_id=?
The third select is superfluous because the relationship is already completely known: you already have the customer, so why not just set it on the address entity?
Making the address field in Customer a @ManyToOne doesn't make a difference.
Making the customer field in Address a @OneToMany does remove the extra select, but forces our model to change the relationship from Customer to List<Customer> where we *know* there'll be only 1 element.
Apparently Hibernate can figure out the reverse relationship with a @ManyToOne - @OneToMany without the need for additional queries, can't this be extended to @OneToOne bidirectional relationships as well?
--
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
[Hibernate-JIRA] Created: (HHH-4881) restrict polymorphic query results
by Domenico Loiacono (JIRA)
restrict polymorphic query results
----------------------------------
Key: HHH-4881
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4881
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.0-Beta-4
Environment: Hibernate 3.5.0-Beta-4, MySQL 5.1 Glassfish v3
Reporter: Domenico Loiacono
I'm using JPA 2.0, Hibernate 3.5.0-Beta4, MySQL 5.1 on Glassfish v3.
I want to limit the polymorphic query results using JPA 2.0 syntax (TYPE) :
SELECT e FROM Employee e WHERE TYPE(e) IN (FullTime, Executive)
but it seems that Hibernate 3.5.0-Beta4 doesn't support this syntax because in the generated sql query the 'type' keyword remains unmapped and MySQL throws an Exception:
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '(type(employee0_.id) in (5))' at line 1
So I tried with Criteria API:
CriteriaBuilder criteriaBuilder = em.getCriteriaBuilder();
CriteriaQuery<Employee> criteria = criteriaBuilder.createQuery(Employee.class);
Root<Employee> employee= criteria.from(Employee.class);
criteria.where(employee.type().in(FullTime.class,Executive.class));
But I received an Exception:
Caused by: java.lang.IllegalArgumentException: Unexpected call on EntityTypeExpression#render
at org.hibernate.ejb.criteria.expression.PathTypeExpression.render(PathTypeExpression.java:48)
at org.hibernate.ejb.criteria.predicate.InPredicate.render(InPredicate.java:164)
at org.hibernate.ejb.criteria.QueryStructure.render(QueryStructure.java:258)
at org.hibernate.ejb.criteria.CriteriaQueryImpl.render(CriteriaQueryImpl.java:340)
at org.hibernate.ejb.criteria.CriteriaQueryCompiler.compile(CriteriaQueryCompiler.java:150)
at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:416)
at com.sun.enterprise.container.common.impl.EntityManagerWrapper.createQuery(EntityManagerWrapper.java:489)
So I opened the PathTypeExpression class and in the render method I saw :
public String render(CriteriaQueryCompiler.RenderingContext renderingContext) {
// todo : is it valid for this to get rendered into the query itself?
throw new IllegalArgumentException( "Unexpected call on EntityTypeExpression#render" );
}
Then I switched to use Hibernate custom query syntax (class) :
SELECT e FROM Employee e WHERE (e.class) IN (FullTime, Executive)
Ok this works fine.
But when I add a join with another entity (Department) that has the same TABLE_PER_CLASS inheritance strategy of entity Employee, I have a new problem:
SELECT e FROM Employee e JOIN e.departments d WHERE d.code = 'D1' and (e.class) IN (FullTime, Executive)
GRAVE: Column 'clazz_' in where clause is ambiguous
Caused by: javax.persistence.PersistenceException: org.hibernate.exception.ConstraintViolationException: could not execute query
--
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
[Hibernate-JIRA] Created: (HHH-2866) The order of parameters is not maintained between HQL and SQL, but the parameters are inserted into the PreparedStatement in their HQL order.
by Benjamin Keil (JIRA)
The order of parameters is not maintained between HQL and SQL, but the parameters are inserted into the PreparedStatement in their HQL order.
---------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2866
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2866
Project: Hibernate3
Issue Type: Bug
Components: query-hql
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5.ga; both with MySQLInnoDB and H2 dialects; both with annotations and hand written mapping files
Reporter: Benjamin Keil
Attachments: ReorderedParameters.java, ReorderedParameters.zip
The HQL query
from Assoc a where a.type.oid = ? and a.constituents[?].oid = ?
gets translated into
select
reorderedp0_.oid as oid1_,
reorderedp0_.type_oid as type2_1_
from
Assoc reorderedp0_,
Assoc_Topic constituen1_,
Topic reorderedp2_
where
reorderedp0_.oid=constituen1_.Assoc_oid
and constituen1_.topic_index = ?
and constituen1_.constituents_oid=reorderedp2_.oid
and reorderedp0_.type_oid=?
and reorderedp2_.oid=?
Where clearly the first and second parameters (the index and the type) have been permuted.
The relevant thread in the User forum is : http://forum.hibernate.org/viewtopic.php?t=979832
Attached are a java source file that demonstrates the error, and a zipped maven2 project that supplies the Hibernate, Hibernate-Annotation, H2, and Log4J dependencies.
--
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, 1 month
[Hibernate-JIRA] Created: (HSEARCH-46) Race condition in manual index update
by Christian Bauer (JIRA)
Race condition in manual index update
-------------------------------------
Key: HSEARCH-46
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-46
Project: Hibernate Search
Issue Type: Bug
Components: engine
Reporter: Christian Bauer
log.info("rebuilding Lucene index");
Class[] entityTypes = { Document.class, File.class, Comment.class, Faq.class};
EntityManager em = (EntityManager) Component.getInstance("entityManager");
FullTextSession ftSession = org.hibernate.search.Search.createFullTextSession( (Session) em.getDelegate() );
for (Class entityType : entityTypes) {
for (Object o : ((Session) em.getDelegate()).createCriteria(entityType).list()) {
ftSession.index(o);
}
}
08:23:39,419 INFO [WikiInit] rebuilding Lucene index
08:23:39,532 DEBUG [ManagedPersistenceContext] created seam managed persistence context from EntityManagerFactory
08:23:39,553 INFO [STDOUT] Hibernate: /* criteria query */ select this_.NODE_ID as NODE2_1_1_, this_.AREA_NR as AREA3_1_1_, this_.CREATED_BY_USER_ID as CREATED17_1_1_, this_.CREATED_ON as CREATED4_1_1_, this_.LAST_MODIFIED_BY_USER_ID as LAST18_1_1_, this_.LAST_MODIFIED_ON as LAST5_1_1_, this_.MENU_ITEM as MENU6_1_1_, this_.NAME as NAME1_1_, this_.PARENT_NODE_ID as PARENT20_1_1_, this_.READ_ACCESS_LEVEL as READ8_1_1_, this_.NODE_REVISION as NODE9_1_1_, this_.OBJ_VERSION as OBJ10_1_1_, this_.WIKINAME as WIKINAME1_1_, this_.WRITE_ACCESS_LEVEL as WRITE12_1_1_, this_.ENABLE_COMMENT_FORM as ENABLE14_1_1_, this_.ENABLE_COMMENTS as ENABLE15_1_1_, this_.NAME_AS_TITLE as NAME16_1_1_, node2_.NODE_ID as NODE2_1_0_, node2_.AREA_NR as AREA3_1_0_, node2_.CREATED_BY_USER_ID as CREATED17_1_0_, node2_.CREATED_ON as CREATED4_1_0_, node2_.LAST_MODIFIED_BY_USER_ID as LAST18_1_0_, node2_.LAST_MODIFIED_ON as LAST5_1_0_, node2_.MENU_ITEM as MENU6_1_0_, node2_.NAME as NAME1_0_, node2_.PARENT_NODE_ID as PARENT20_1_0_, node2_.READ_ACCESS_LEVEL as READ8_1_0_, node2_.NODE_REVISION as NODE9_1_0_, node2_.OBJ_VERSION as OBJ10_1_0_, node2_.WIKINAME as WIKINAME1_0_, node2_.WRITE_ACCESS_LEVEL as WRITE12_1_0_, node2_.DEFAULT_DOCUMENT_ID as DEFAULT19_1_0_, node2_.ENABLE_COMMENT_FORM as ENABLE14_1_0_, node2_.ENABLE_COMMENTS as ENABLE15_1_0_, node2_.NAME_AS_TITLE as NAME16_1_0_, node2_1_.CONTENT_TYPE as CONTENT1_2_0_, node2_1_.FILENAME as FILENAME2_0_, node2_1_.FILESIZE as FILESIZE2_0_, node2_1_.IMAGE_SIZE_X as IMAGE5_2_0_, node2_1_.IMAGE_SIZE_Y as IMAGE6_2_0_, node2_1_.IMAGE_THUMBNAIL as IMAGE7_2_0_, node2_.NODE_TYPE as NODE1_1_0_ from NODE this_ left outer join NODE node2_ on this_.PARENT_NODE_ID=node2_.NODE_ID left outer join NODE_FILE node2_1_ on node2_.NODE_ID=node2_1_.FILE_ID where this_.NODE_TYPE='DOCUMENT'
08:23:39,587 INFO [STDOUT] Hibernate: /* load org.jboss.seam.wiki.core.model.Node */ select node0_.NODE_ID as NODE2_1_1_, node0_.AREA_NR as AREA3_1_1_, node0_.CREATED_BY_USER_ID as CREATED17_1_1_, node0_.CREATED_ON as CREATED4_1_1_, node0_.LAST_MODIFIED_BY_USER_ID as LAST18_1_1_, node0_.LAST_MODIFIED_ON as LAST5_1_1_, node0_.MENU_ITEM as MENU6_1_1_, node0_.NAME as NAME1_1_, node0_.PARENT_NODE_ID as PARENT20_1_1_, node0_.READ_ACCESS_LEVEL as READ8_1_1_, node0_.NODE_REVISION as NODE9_1_1_, node0_.OBJ_VERSION as OBJ10_1_1_, node0_.WIKINAME as WIKINAME1_1_, node0_.WRITE_ACCESS_LEVEL as WRITE12_1_1_, node0_.DEFAULT_DOCUMENT_ID as DEFAULT19_1_1_, node0_.ENABLE_COMMENT_FORM as ENABLE14_1_1_, node0_.ENABLE_COMMENTS as ENABLE15_1_1_, node0_.NAME_AS_TITLE as NAME16_1_1_, node0_1_.CONTENT_TYPE as CONTENT1_2_1_, node0_1_.FILENAME as FILENAME2_1_, node0_1_.FILESIZE as FILESIZE2_1_, node0_1_.IMAGE_SIZE_X as IMAGE5_2_1_, node0_1_.IMAGE_SIZE_Y as IMAGE6_2_1_, node0_1_.IMAGE_THUMBNAIL as IMAGE7_2_1_, node0_.NODE_TYPE as NODE1_1_1_, node1_.NODE_ID as NODE2_1_0_, node1_.AREA_NR as AREA3_1_0_, node1_.CREATED_BY_USER_ID as CREATED17_1_0_, node1_.CREATED_ON as CREATED4_1_0_, node1_.LAST_MODIFIED_BY_USER_ID as LAST18_1_0_, node1_.LAST_MODIFIED_ON as LAST5_1_0_, node1_.MENU_ITEM as MENU6_1_0_, node1_.NAME as NAME1_0_, node1_.PARENT_NODE_ID as PARENT20_1_0_, node1_.READ_ACCESS_LEVEL as READ8_1_0_, node1_.NODE_REVISION as NODE9_1_0_, node1_.OBJ_VERSION as OBJ10_1_0_, node1_.WIKINAME as WIKINAME1_0_, node1_.WRITE_ACCESS_LEVEL as WRITE12_1_0_, node1_.DEFAULT_DOCUMENT_ID as DEFAULT19_1_0_, node1_.ENABLE_COMMENT_FORM as ENABLE14_1_0_, node1_.ENABLE_COMMENTS as ENABLE15_1_0_, node1_.NAME_AS_TITLE as NAME16_1_0_, node1_1_.CONTENT_TYPE as CONTENT1_2_0_, node1_1_.FILENAME as FILENAME2_0_, node1_1_.FILESIZE as FILESIZE2_0_, node1_1_.IMAGE_SIZE_X as IMAGE5_2_0_, node1_1_.IMAGE_SIZE_Y as IMAGE6_2_0_, node1_1_.IMAGE_THUMBNAIL as IMAGE7_2_0_, node1_.NODE_TYPE as NODE1_1_0_ from NODE node0_ left outer join NODE_FILE node0_1_ on node0_.NODE_ID=node0_1_.FILE_ID left outer join NODE node1_ on node0_.PARENT_NODE_ID=node1_.NODE_ID left outer join NODE_FILE node1_1_ on node1_.NODE_ID=node1_1_.FILE_ID where node0_.NODE_ID=?
08:23:39,654 INFO [STDOUT] Hibernate: /* criteria query */ select this_.COMMENT_ID as COMMENT1_4_0_, this_.CREATED_ON as CREATED2_4_0_, this_.DOCUMENT_ID as DOCUMENT9_4_0_, this_.FROM_USER_EMAIL as FROM3_4_0_, this_.FROM_USER_HOMEPAGE as FROM4_4_0_, this_.FROM_USER_NAME as FROM5_4_0_, this_.SUBJECT as SUBJECT4_0_, this_.COMMENT_TEXT as COMMENT7_4_0_, this_.OBJ_VERSION as OBJ8_4_0_ from COMMENTS this_
08:23:39,662 INFO [STDOUT] Hibernate: /* criteria query */ select this_.FAQ_ID as FAQ1_7_0_, this_.ANSWER as ANSWER7_0_, this_.CREATED_ON as CREATED3_7_0_, this_.QUESTION as QUESTION7_0_, this_.RATING as RATING7_0_, this_.OBJ_VERSION as OBJ6_7_0_ from FAQ this_
08:23:39,665 DEBUG [Work] committing transaction
08:23:39,807 ERROR [AssertionFailure] an assertion failure occured (this may indicate a bug in Hibernate)
org.hibernate.annotations.common.AssertionFailure: Tries to read for update a index while a writer is accessedclass org.jboss.seam.wiki.core.model.Document
at org.hibernate.search.backend.Workspace.getIndexReader(Workspace.java:54)
at org.hibernate.search.backend.impl.lucene.LuceneWorker.remove(LuceneWorker.java:81)
at org.hibernate.search.backend.impl.lucene.LuceneWorker.performWork(LuceneWorker.java:69)
at org.hibernate.search.backend.impl.lucene.LuceneWorker.performWork(LuceneWorker.java:40)
at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueProcessor.run(LuceneBackendQueueProcessor.java:36)
at org.hibernate.search.backend.impl.BatchedQueueingProcessor.performWork(BatchedQueueingProcessor.java:116)
at org.hibernate.search.backend.impl.PostTransactionWorkQueueSynchronization.afterCompletion(PostTransactionWorkQueueSynchronization.java:49)
at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:136)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:342)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:95)
at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177)
--
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, 1 month
[Hibernate-JIRA] Created: (HHH-4723) Column in SQL query is returned as java.lang.Character
by Nick de Graeve (JIRA)
Column in SQL query is returned as java.lang.Character
------------------------------------------------------
Key: HHH-4723
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4723
Project: Hibernate Core
Issue Type: Bug
Components: query-sql
Affects Versions: 3.3.1
Reporter: Nick de Graeve
When I run this code sample:
{{List data = session.createSQLQuery("select e.country_iso_code from agent.tbd3_Entry e where e.country_iso_code = 'BE'").list();}}
{{Object row = data.get(0);}}
{{System.out.print(row + ": " + row.getClass());}}
I get this result:
{{B: class java.lang.Character}}
I expect to get a {{java.lang.String}} containing "BE", not just the 1st Character.
The column country_is_code of table tbd3_entry is defined in Oracle as {{COUNTRY_ISO_CODE CHAR(2 BYTE)}}
When I add a scalar with correct type I do get what I need:
{{List data = session.createSQLQuery("select e.country_iso_code countryIsoCode from agent.tbd3_Entry e where e.country_iso_code = 'BE'").addScalar("countryIsoCode", Hibernate.STRING).list();}}
{{Object row = data.get(0);}}
{{System.out.print(row + ": " + row.getClass());}}
results in
{{BE: class java.lang.String}}
--
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, 1 month
[Hibernate-JIRA] Created: (HHH-3313) Criteria + Property Projection + LockMode causes a NPE
by Christian Nelson (JIRA)
Criteria + Property Projection + LockMode causes a NPE
------------------------------------------------------
Key: HHH-3313
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3313
Project: Hibernate3
Issue Type: Bug
Components: query-criteria
Affects Versions: 3.2.6
Environment: Hibernate 3.2.6.ga, PostgreSQL 8.1
Reporter: Christian Nelson
Attachments: hibernate-criteria-projection-lockmode-project.zip
In converting a working HQL query to the Criteria API, we stumbled upon what looks very much like a bug. When combining a criteria with a projection and setting the lockmode (to read or upgrade), hibernate throws a NPE down in CriteriaLoader.applyLocks().
Here's a simplified snippet of the criteria that results in the exception:
Criteria criteria = session.createCriteria(Article.class).add(Restrictions.ilike("title", "%frozen%"));
criteria.createCriteria("moderation", "m").add(Restrictions.eq("approved", true));
criteria.setProjection(Projections.property("moderation"));
criteria.setLockMode("m", LockMode.UPGRADE);
assertions(criteria.list());
[The test case includes other attempts at building a similar criteria using different approaches.]
And here's the stack trace:
java.lang.NullPointerException
at org.hibernate.loader.criteria.CriteriaLoader.applyLocks(CriteriaLoader.java:131)
at org.hibernate.loader.Loader.preprocessSQL(Loader.java:201)
at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1538)
at org.hibernate.loader.Loader.doQuery(Loader.java:673)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
at org.hibernate.loader.Loader.doList(Loader.java:2213)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2104)
at org.hibernate.loader.Loader.list(Loader.java:2099)
at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:94)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1569)
at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:283)
There's already some talk on the web about this problem:
* http://forum.hibernate.org/viewtopic.php?t=955525
* http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=78...
I've created a simplified test case which includes the HQL version of the query (works), the Criteria version without lockmode (works), and then 3 failing tests illustrating the problem. The attached zip contains the test case and supporting files. The source code for the test case is also available via anonymous svn access (http://svn.carbonfive.com/public/christian/hibernate-criteria-projection-...). The test will run out of the box using maven against an h2database in-memory database with no setup.
This combination of features doesn't seem that obscure so I'd expect it to work, or at the very least, report that it is not supported in a more graceful manner.
--
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, 1 month