November 2008 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Commented: (HV-16) Validator ignores components

by Rene Parra (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HV-16?page=com.... ] Rene Parra commented on HV-16: ------------------------------ Possible work around is the following: Annotate the entity with a "fake property" that exposes the component's property. For example: Assume the following: * Assume Entity "A" has component "B". * "B" has a property "fooProp" that we wish to annotate with a Hibernate Validator constraint. Because of HV-16, we cannot annotate B.fooProp because it will be ignored. Possible workaround is -- create a "fake property" that exposes "fooProp" on entity A; then annotate A.fooProp. public class A ... { // assume these methods because B is a component of A private B; public B getB(); @Length(max=255) public T getFooProp() { return getB().getFooProp(); } } All the regular setters/getters can be on B. I did not test this on schema generation. This was only tested with Hibernate Validator for insert/update precondition testing. Also the errors will be on A (not on the component B), so special mapping must be done if this is to be reported in the UI. This has the added benefit that when HV-16 is fixed, the migration should be fairly straightforward. > Validator ignores components > ---------------------------- > > Key: HV-16 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-16 > Project: Hibernate Validator > Issue Type: Bug > Components: engine > Reporter: Emmanuel Bernard > -- 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

15 years, 6 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-104) Make @DocumentId optional and rely on @Id

by Emmanuel Bernard (JIRA)

Make @DocumentId optional and rely on @Id ----------------------------------------- Key: HSEARCH-104 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-104 Project: Hibernate Search Issue Type: New Feature Components: mapping Reporter: Emmanuel Bernard Priority: Minor -- 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

15 years, 6 months

2
6
0 / 0

[Hibernate-JIRA] Commented: (HHH-1152) Value object(<component>) inheritance mapping

by Stefan Fromm (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1152?page=c... ] Stefan Fromm commented on HHH-1152: ----------------------------------- I'm trying to implement the Role Object Pattern for domain objects. I would need component inheritance for the role objects. Treating them as entities is not possible, because they appear to be the same object as their core object - they have the same identity. Adding more than 1 role object to the core object results in a NonUniqueObjectException. I have to change back my domain model to the Extension Object Pattern where the extension/role objects are not identical to their core object. I agree with Ilya. "table per class hierarchy" would suffice initially. > Value object(<component>) inheritance mapping > --------------------------------------------- > > Key: HHH-1152 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1152 > Project: Hibernate Core > Issue Type: New Feature > Components: core > Affects Versions: 3.1 beta 2 > Reporter: Vjeran Marcinko > Priority: Minor > > Though fine-grained object mapping is one of Hibernate's main objectives, it still doesn't support *value object* (<component>) inheritance mapping, only entity inheritance mapping. > It would be best if <component> tag could also contain similar tags for inheritance as entity does. -- 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

15 years, 6 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-293) AddLuceneWork is not being removed from the queue when DeleteLuceneWork is added for the same entity

by Daniel Claesén (JIRA)

AddLuceneWork is not being removed from the queue when DeleteLuceneWork is added for the same entity ---------------------------------------------------------------------------------------------------- Key: HSEARCH-293 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-293 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.1.0.Beta2 Reporter: Daniel Claesén There's an issue in the addWorkToQueue function in the DocumentBuilder class. If the work type is delete and there is an AddLuceneWork for the same entity in the queue it is added to the toDelete list. But when looping through the toDelete list the items are not removed from the LuceneWork queue, only from the toDelete list. -- 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

15 years, 6 months

3
6
0 / 0

[Hibernate-JIRA] Created: (HHH-3592) Configuring naming strategy declaratively

by Fol De Rol (JIRA)

Configuring naming strategy declaratively ----------------------------------------- Key: HHH-3592 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3592 Project: Hibernate Core Issue Type: Improvement Reporter: Fol De Rol I wonder why the naming strategy can only be configured using a programmatic approach by calling Configuration.setNamingStrategy() method? It would be helpful to have a way to define the naming strategy class name in properties so that Hibernate instantiated it using reflection on a default constructor. IDEA IDE has an outstanding built-in HQL console which is not working if a non-default naming strategy is used because it produces SQL with wrong object names. The only way to configure a session is by providing a Hibernate configuration file. -- 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

15 years, 6 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-250) In ReaderStrategies, ensure that the reader is current AND that the directory returned by the DirectoryProvider are the same

by Emmanuel Bernard (JIRA)

In ReaderStrategies, ensure that the reader is current AND that the directory returned by the DirectoryProvider are the same ---------------------------------------------------------------------------------------------------------------------------- Key: HSEARCH-250 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-250 Project: Hibernate Search Issue Type: Bug Affects Versions: 3.1.0.Beta1 Reporter: Emmanuel Bernard Priority: Critical Fix For: 3.1.0.Beta2 When using the cluster mode, s slave has an active copy (current) and a passive copy of a Directory. In ReaderStrategy, we ensure the IndexReader is current but we do not ensure the Directory is the active one. -- 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

15 years, 6 months

3
10
0 / 0

[Hibernate-JIRA] Created: (ANN-527) reference a target entity (in a collection) by entity name

by Armin Haaf (JIRA)

reference a target entity (in a collection) by entity name ---------------------------------------------------------- Key: ANN-527 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-527 Project: Hibernate Annotations Type: New Feature Components: binder Reporter: Armin Haaf It is only possible to reference a targetEntity by class. @ManyToMany(targetEntity = TestImpl.class) List<Test> myList; This makes it impossible to exchange TestImpl.class implemention by another implemention by the mappings definition. It would be helpful to reference a targetEntity by name. @ManyToMany(targetEntityName = "Test") This would help a lot to implement moduls and frameworks. Another way to support this would be to search for a implementation of the collection elements (which are typically Interfaces) in the mapped entities -- 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

15 years, 6 months

5
10
0 / 0

[Hibernate-JIRA] Commented: (HHH-1268) Unidirection OneToMany causes duplicate key entry violation when removing from list

by Avram Cherry (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1268?page=c... ] Avram Cherry commented on HHH-1268: ----------------------------------- Wow, I just ran into this issue 2 years after I first encountered it... I'm pretty surprised it's still not been fixed. I'm stuck using a db model that I can't really make any changes to, so I can't alter it to treat (PK, ordinal) as the join table's primary key with the FK unconstrained. My primary key is on the join table is instead (PK,FK) with (PK,Ordinal) as an additional unique constraint. A work-around that I'm using right now is to simply replace the PersistentList instance with a fresh (non-persistent) List with the same contents whenever you re-order values in it. This causes Hibernate to do: DELETE from jointable where pk=? And then re-insert all of the relevant rows. Considering that Hibernate would have to update every single row who's index has changed anyway using its current logic, doing a delete/insert like this doesn't perform all that much worse and I believe would be an acceptable long-term solution to this bug. It has the added bonus of working with any (reasonable) combination of primary-key and unique constraints on the join table. An 'ideal' solution would be to have the CollectionPersister find each 'continuous' block of list items that have not changed in relative order, but has shifted position within the whole list and perform: First: Delete rows that have actually be removed entirely from the list. This will leave 'holes' in the table, but ensure that the next operation won't violate any constraints. Second, for each continuous block that needs to be moved: UPDATE jointable set ordinal = ordinal + :shiftAmount where PK = :pkid and ordinal BETWEEN :firstIndex and :lastIndex Finally: Insert rows that are actually new to the list. This will fill in any remaining holes that we created in step 1. This is complicated, though and would probably be difficult to implement correctly but would potentially reduce the number of updates that would have to be made when an indexed list gets reordered. So, until/unless some sort of better behavior comes along, can anybody think of a reason why having Hibernate do a delete/re-insert would be worse than keeping this bug? > Unidirection OneToMany causes duplicate key entry violation when removing from list > ----------------------------------------------------------------------------------- > > Key: HHH-1268 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1268 > Project: Hibernate Core > Issue Type: Bug > Affects Versions: 3.1 > Environment: 3.1 final > MySql 4.1.14 using MYISAM tables > Reporter: Rex Madden > Assignee: Gail Badner > Fix For: 3.2.x, 3.3.x > > Attachments: src.zip > > > Simple OneToMany parent/child relationship using the default table structure (2 tables and a join table) > Add 3 children to the parent. Flush. Remove the first child. Flush throws error: > Exception in thread "main" org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update > at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:69) > at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) > at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:202) > at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:230) > at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:143) > at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:296) > at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) > at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:980) > at UnidirectionalOneToManyRemoveFromListBug.main(UnidirectionalOneToManyRemoveFromListBug.java:27) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:86) > Caused by: java.sql.BatchUpdateException: Duplicate key or integrity constraint violation, message from server: "Duplicate entry '5' for key 2" > at com.mysql.jdbc.PreparedStatement.executeBatch(PreparedStatement.java:1461) > at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:58) > at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:195) > ... 11 more > The problem is that there is a unique key on the relationship table that gets violated. The session removes the last row in the relationship table, then attempts to rewrite the child_id's. It fails since there is a uniqueness constraint on that column. -- 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

15 years, 6 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-291) improve documentation about thread safety requirements of Bridges.

by Sanne Grinovero (JIRA)

improve documentation about thread safety requirements of Bridges. ------------------------------------------------------------------ Key: HSEARCH-291 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-291 Project: Hibernate Search Issue Type: Task Components: documentation Reporter: Sanne Grinovero Priority: Minor Fix For: 3.1.0.CR1 -- 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

15 years, 6 months

1
2
0 / 0

[Hibernate-JIRA] Created: (ANN-781) OneToMany relationship in Composite PK Entity causes PropertyAccessException

by Parmendra Kumar Tyagi (JIRA)

OneToMany relationship in Composite PK Entity causes PropertyAccessException ---------------------------------------------------------------------------- Key: ANN-781 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-781 Project: Hibernate Annotations Issue Type: Bug Affects Versions: 3.2.0.ga Environment: Hibernate Core - 3.2.4.sp1,Database - Oracle 10g Reporter: Parmendra Kumar Tyagi Priority: Blocker Attachments: code.zip I need to create @OneToMany join between two tables using join on two non-directly related columns. So i have create a @OneToMany relationship in a entity which has a composite primary key. This relation cause PropertyAccessException. -- 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

15 years, 6 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues November 2008