[Hibernate-JIRA] Created: (HHH-3160) Support one-to-many list associations with constraints on both (owner_id, position) and (child_id)
by Gail Badner (JIRA)
Support one-to-many list associations with constraints on both (owner_id, position) and (child_id)
--------------------------------------------------------------------------------------------------
Key: HHH-3160
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3160
Project: Hibernate3
Issue Type: Sub-task
Reporter: Gail Badner
Assignee: Gail Badner
The logic used for removing entities from one-to-many list associations can cause ConstraintViolationException will be thrown if there are constraints on both (owner_id, position) and (child_id) in the "collection table". If the association is on a join table, the "collection table" is the join table; otherwise, the "collection table" is the child entity table..
Currently, SchemaExport does not put a constraint on (owner_id, position) when exporting one-to-many list associations on a foreign key. SchemaExport should be updated to also export this constraint.
See HHH-1268 for a description of how to reproduce this issue.
For one-to-many list associations on a foreign key, the workaround is to either define the constraint on (owner_id, position) in the child entity table as deferred. If this is not on option for a particular Dialect, the constraint on (owner_id, position) will have to be excluded.
For a one-to-many list association on a join table, the workaround is to either define the constraint on (child_id) in the join table as deferred. If this is not on option for a particular Dialect, the constraint on (child_id) will have to be excluded.
--
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, 9 months
[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
14 years, 10 months
[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
14 years, 10 months
[Hibernate-JIRA] Created: (HSEARCH-159) Sort + Pagination returns wrong results.
by Jason Eacott (JIRA)
Sort + Pagination returns wrong results.
----------------------------------------
Key: HSEARCH-159
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-159
Project: Hibernate Search
Issue Type: Bug
Affects Versions: 3.0.1.GA
Environment: hib 3.2.5ga
Reporter: Jason Eacott
Perhaps I am doing something wrong?
Using the code below if I call
getSearchResults("test",0,10); //returns incorrect data
I get a different item at the head of the list than if I call
getSearchResults("test",0,100);// (this one has correct data, total results for this search is 196 in my ndx & db)
if I dont try to paginate the results then the sort items are in order and are correct.
and if I paginate with just 1 result
getSearchResults("test",0,1);
and change the sort order I get the same result for each attempt: ie:
Sort datesort=new Sort( new SortField( "date_time", SortField.STRING, true ) );
and
Sort datesort=new Sort( new SortField( "date_time", SortField.STRING, false ) );
return the same entry - which is NOT the correct result either.
This behavious seems to indicate that the data is being sorted after the limit is set
and whats worse, if there are 50,000,000 results, even though I only want 10 and hibernate has already correctly hydrated those 10 (albeit the wrong 10) hibernatesearch then loops over all 50,000,000 hits and creates a new (empty) hibernate proxy object for each & discard all but 10!
...
@Field(name="date_time", index=Index.UN_TOKENIZED, store=Store.NO)
@DateBridge(resolution=Resolution.MINUTE)
private Date publishDate;
...
public List getSearchResults(Query query,int firstResult,int maxResults) {
List result=null;
Session sess=null;
Transaction tx = null;
try {
sess=getSessionFactory().openSession();
FullTextSession fullTextSession = Search.createFullTextSession(sess);
tx = fullTextSession.beginTransaction();
tx.begin();
org.hibernate.search.FullTextQuery hibQuery= fullTextSession.createFullTextQuery( query, FeedItem.class );
Sort datesort=new Sort( new SortField( "date_time", SortField.STRING, true ) );
hibQuery.setSort(datesort);
Criteria dbCr=fullTextSession.createCriteria(FeedItem.class);
hibQuery.setCriteriaQuery(dbCr);
dbCr.setFirstResult(firstResult);
dbCr.setMaxResults(maxResults);
}
long resultSize=hibQuery.getResultSize();
if (resultSize>0){
result = hibQuery.list()
}
tx.commit();
}
finally
{
releaseSession(sess);
tx=null;
}
log.debug("<getSearchResults");
return result;
}
--
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, 10 months
[Hibernate-JIRA] Created: (HHH-2220) session.createSQLQuery(sql) translates database type CHAR(n) to Java type char instead of String
by Regis Pires Magalhaes (JIRA)
session.createSQLQuery(sql) translates database type CHAR(n) to Java type char instead of String
------------------------------------------------------------------------------------------------
Key: HHH-2220
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2220
Project: Hibernate3
Type: Bug
Components: query-sql
Versions: 3.2.0.ga
Reporter: Regis Pires Magalhaes
createSQLQuery() method translates database type CHAR(n) to Java type char instead of String when using setResultTransformer(Criteria.ALIAS_TO_ENTITY_MAP).
That happens when I do not use addScalar(). And that is the only problem that I have found when not filling return types in advance.
A workaround I have made is to concatenate the projected field with an empty string (''). See example below:
...
query.setResultTransformer(Criteria.ALIAS_TO_ENTITY_MAP);
String sqlQuery = "select s.name state from state s where s.name='PI' ";
query = session.createSQLQuery(sqlQuery);
...
result: [{STATE=P}]
name field is CHAR(2) in database definition (PostgreSQL, HSQLDB and Oracle were tested).
Note that it works when I concatenate the field used in projection with an empty string:
...
String sqlQuery = "select s.name || '' state from state s where s.name='PI' ";
...
result: [{STATE=PI}]
--
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, 10 months
[Hibernate-JIRA] Created: (HHH-2429) SQL Character Types Incorrectly mapped to Java objects
by Tyler Van Gorder (JIRA)
SQL Character Types Incorrectly mapped to Java objects
------------------------------------------------------
Key: HHH-2429
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2429
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.1
Environment: Hibernate 3.2.1, Oracle10g
Reporter: Tyler Van Gorder
We have a work flow that allows the user to enter an arbitrary SQL statement to be executed by our application. We pass those queries through session.createSQLQuery().
We ran into a problem with String literals, which are reported by Oracle (ResultSetMetaData) to be CHAR. Reading the JDBC API, CHAR is a fixed length string. Hibernate is incorrectly mapping this to a Character field. We ended up overriding the Oracle dialect with our own as follows:
In our constructor, for a dialect that extends Oracle9iDialect:
super()
registerColumnType(Types.CHAR, "char($l)" );
registerHibernateType( Types.CHAR, Hibernate.STRING.getName() );
The HibernateType is the crucial one and we are overriding the behavior in the base "Dialect" class, so this appears that it would be a problem for all database variants that don't explicitly change this.
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, 10 months