September 2008 - hibernate-issues

[Hibernate-JIRA] Created: (HHH-3455) Component polymorphism (<subclass> within <component>)

by Jasper Blues (JIRA)

Component polymorphism (<subclass> within <component>) ------------------------------------------------------ Key: HHH-3455 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3455 Project: Hibernate3 Issue Type: Improvement Components: core Reporter: Jasper Blues The following feature request occurs on the Hibernate forums from time to time - it would be especially useful in mapping complex legacy schemas: <class name="Critter"> <component name="breathingStrategy" class="BreathingStrategy"> <discriminator column="BREATHING_STRATEGY" type="integer" /> <subclass name="Lungs" discriminator-value="0" > <set name="alveoli"> <key column="CRITTER_ID" /> <one-to-many class="Alveolus" /> </set> </subclass> <subclass name="Gills" discriminator-value="1" > <set name="alveoli"> <key column="CRITTER_ID" /> <one-to-many class="Gill" /> </set> </subclass> </component> </class> Will a patch that implements this feature be accepted? What do you think if there was an option to inherit a discriminator from the owning entity? How about some convention over configuration? By default the discriminator from the owning entity is inherited, unless one is supplied at the component level. Would an equivalent annotation mapping be required? -- 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

17 years, 1 month

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-2920) Polymorphic association with explicit table_per_class strategy: properties of subclass are not retrieved by queries.

by Andrea Silva (JIRA)

Polymorphic association with explicit table_per_class strategy: properties of subclass are not retrieved by queries. -------------------------------------------------------------------------------------------------------------------- Key: HHH-2920 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2920 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.5 Environment: Java 1.5 - Hypersonic DB - Standalone application Reporter: Andrea Silva Priority: Minor Attachments: src.zip Item class has a one-to-many association to Bid. Bid class has a subclass called CashBid (meaningless design I know, but that's not the point). If I create and save an instance of Item with an associated CashBid, when I query for items the properties defined in CashBid are not retrieved. NB Bid is not mapped as abstract. Here is a code snippet: ... // First Session Session session = sessionFactory.openSession(); Transaction transaction = session.beginTransaction(); Bid bid = new CashBid(new BigDecimal(100.0d), "euro"); Item item = new Item("pc"); Serializable bidId = session.save(bid); item.addBid(bid); session.save(item); transaction.commit(); session.close(); // Second Session session = sessionFactory.openSession(); transaction = session.beginTransaction(); //session.load(CashBid.class, bidId); Query query = session.createQuery("from Item"); List<Item> list = query.list(); for (Item item_ : list) { System.out.println(item_); } transaction.commit(); session.close(); ... The bid in the item retrieved by the query is a CashBid (that's correct) but the properties that are defined in CashBid and not in Bid are null. If I uncomment the line //session.load(CashBid.class, bidId); the problem is not there anymore. If Bid is not mapped as abstract the problem doesn't show. My apologies if I'm just missing something very obvious. Please find the source code and the mappings attached. -- 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

17 years, 1 month

4
5
0 / 0

[Hibernate-JIRA] Created: (HHH-3371) Criteria Query Issue with Projection and restriction

by Michael Kuhinica (JIRA)

Criteria Query Issue with Projection and restriction ---------------------------------------------------- Key: HHH-3371 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3371 Project: Hibernate3 Issue Type: Bug Components: query-criteria Affects Versions: 3.2.6 Environment: Hibernate version: 3.2.6ga, MySQL 5 Reporter: Michael Kuhinica When I try to add a restriction to a property with a projection, hibernate generate the SQL using the property alias on the where clause instead of the property name. Here is an code example: Criteria c = session.createCriteria(Customer.class).setProjection( Projections.projectionList() .add(Projections.property(Customer.PROP_ID), "id") .add(Projections.property(Customer.PROP_NAME), "name") ) .add(Restrictions.like(Customer.PROP_EMAIL, email)) .add(Restrictions.like(Customer.PROP_NAME, name)); And the generated SQL: select this_.ctm_id as y0_, this_.ctm_name as y1_ from customers this_ where this_.ctm_mail like ? and y1_ like ? Notice that hibernate used the right name for the customer e-mail (that has no projection on it) but it used an alias for the name that have a projection set. See: http://forum.hibernate.org/posting.php?mode=editpost&p=2388756 -- 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

17 years, 1 month

3
4
0 / 0

[Hibernate-JIRA] Created: (BVAL-15) Object graph traversed too many times

by Emmanuel Bernard (JIRA)

Object graph traversed too many times ------------------------------------- Key: BVAL-15 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-15 Project: Bean Validation Issue Type: Bug Components: ri-general Reporter: Emmanuel Bernard Assignee: Hardy Ferentschik You seem to traverse the object graph once per group. I made the spec so that multiple traversals were not necessary unless you physically force group sequence. Actually the prototype I gave you was doing some clever things to minimize the number of AFAIR I made the spec so that this multiple traversals are not needed unless you physically sequenciate them. In a prototype I had, I actually worked on an algorithm to validate as much groups as possible in a same traversal. Unfortunately I lost it, probably in my hardware crash :( The idea was to compute a tree of groups to validate with their respective sequential constraints and run as less cycle as possible at a given time e=|- a - b (b seq after a) f=|- c - d (d seq after c) validating e, f would run a and c in // in the same cycle and b and d in the second cycle. -- 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

17 years, 1 month

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2792) Session.delete is validate all fields are null

by Daniel Passos (JIRA)

Session.delete is validate all fields are null ---------------------------------------------- Key: HHH-2792 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2792 Project: Hibernate3 Issue Type: Bug Components: core Reporter: Daniel Passos session.delete operation would not have to validate if the fields are null The problem in DefaultDeleteEventListener.deleteEntity -> Nullability.checkNullability -- 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

17 years, 1 month

6
5
0 / 0

[Hibernate-JIRA] Created: (HHH-2801) wrong insert/delete order when updating record-set

by Christoph Mayerhofer (JIRA)

wrong insert/delete order when updating record-set -------------------------------------------------- Key: HHH-2801 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2801 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.4.sp1 Environment: hibernate-3.2.4.sp1, hibernate-annotations-3.3.0.GA, hibernate-entitymanager-3.3.1.GA, Oracle 10g Express Edition Reporter: Christoph Mayerhofer Attachments: model.zip Overview: I have a record with a OneToMany association. From this associated record-set a record is removed and added again, both records identified with the same key. When doing a merge, I get a Unique constraint violation, because Hibernate first tries to insert the new record. Hibernate should first delete the old record, and after this insert the new record, avoiding the unique constraint violation. Detailed description: I have the following entities: Patient, SocialInsurance, PatientSocialInsurance. A patient could have several social insurances assigned to it. A social insurance could be assigned several times to a patient, we have a m:n relation between Patient and SocialInsurance. The relation-table has the name PatientSocialInsurance, with a unique constraint over patient_id and social_insurance_id. Each POJO inherits from a Base-POJO, which holds the id and the insert- and update-timestamps and userstamps. Base ---> PatientEntity ---> Patient Base ---> SocialInsuranceEntity ---> SocialInsurance Base ---> PatientSocialInsuranceEntity ---> PatientSocialInsurance Note: All *Entity model objects are generated with Hibernate-Tools from the db-schema, assuming that there are no wrong annotations, no wrong fields or wrong getter-/setter-methods in these model-classes. (I have enclosed all model-classes within an zipped attachment.) Now I try to delete an existing social insurance from a patient and add the same social insurance to the patient again: public void deleteSocialInsurance(Patient p, PatientSocialInsurance s) { if (p == null || s == null) { throw new IllegalArgumentException(); } s.setSocialInsurance(null); s.setPatient(null); p.getPatientSocialInsurances().remove(s); } public void addPatientSocialInsurance(Patient p, PatientSocialInsurance s) throws DuplicatePatientSocInsException { if (p == null || s == null) { throw new IllegalArgumentException(); } s.setPatient(p); p.getPatientSocialInsurances().add(s); } After doing a merge on the patient object, I get the following error: DEBUG - persisting patient... DEBUG - transaction org.hibernate.ejb.TransactionImpl@44ac6a started DEBUG - update timestamp and userstamp for base record set DEBUG - update timestamp and userstamp for base record set DEBUG - update timestamp and userstamp for base record set DEBUG - update timestamp and userstamp for base record set DEBUG - update timestamp and userstamp for base record set DEBUG - select rawtohex(sys_guid()) from dual DEBUG - insert timestamp and userstamp for base record set DEBUG - insert into dseas.PATIENT_SOCIAL_INSURANCE (TIME_CRE, TIME_UPD, USER_CRE, USER_UPD, CODE_MEMBERSHIP_NO, CODE_TYPE_DEFAULT, PATIENT_ID, SOC_INS_ID, ID) values (?, ?, ?, ?, ?, ?, ?, ?, ?) ERROR - ORA-00001: Unique Constraint (DSEAS.PATIENT_SOCIAL_INSURANCE_UK) verletzt ERROR - ORA-00001: Unique Constraint (DSEAS.PATIENT_SOCIAL_INSURANCE_UK) verletzt ERROR - Could not synchronize database state with session org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:71) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:253) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:237) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:141) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338) at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106) at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:54) at org.dseas.base.hibernate.EntityManagerFacade.commit(EntityManagerFacade.java:78) at org.dseas.business.service.maindata.PatientEditorService.save(PatientEditorService.java:112) at org.dseas.ui.rcp.editor.patient.PatientEditorPart.doSave(PatientEditorPart.java:1298) at org.eclipse.ui.internal.SaveableHelper$1.run(SaveableHelper.java:143) at org.eclipse.ui.internal.SaveableHelper$4.run(SaveableHelper.java:266) at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:369) at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:313) at org.eclipse.jface.window.ApplicationWindow$1.run(ApplicationWindow.java:758) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67) at org.eclipse.jface.window.ApplicationWindow.run(ApplicationWindow.java:755) at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:2451) at org.eclipse.ui.internal.SaveableHelper.runProgressMonitorOperation(SaveableHelper.java:274) at org.eclipse.ui.internal.SaveableHelper.runProgressMonitorOperation(SaveableHelper.java:253) at org.eclipse.ui.internal.SaveableHelper.savePart(SaveableHelper.java:148) at org.eclipse.ui.internal.EditorManager.savePart(EditorManager.java:1345) at org.eclipse.ui.internal.WorkbenchPage.savePart(WorkbenchPage.java:3184) at org.eclipse.ui.internal.WorkbenchPage.saveEditor(WorkbenchPage.java:3197) at org.eclipse.ui.internal.SaveAction.run(SaveAction.java:73) at org.eclipse.jface.action.Action.runWithEvent(Action.java:498) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:545) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:490) at org.eclipse.jface.action.ActionContributionItem$6.handleEvent(ActionContributionItem.java:443) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3682) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3293) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2219) at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:461) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.dseas.ui.rcp.Application.start(Application.java:22) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:153) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:504) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443) at org.eclipse.equinox.launcher.Main.run(Main.java:1169) at org.eclipse.equinox.launcher.Main.main(Main.java:1144) Caused by: java.sql.BatchUpdateException: ORA-00001: Unique Constraint (DSEAS.PATIENT_SOCIAL_INSURANCE_UK) verletzt at oracle.jdbc.driver.DatabaseError.throwBatchUpdateException(DatabaseError.java:343) at oracle.jdbc.driver.OraclePreparedStatement.executeBatch(OraclePreparedStatement.java:10657) at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:48) at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:246) ... 55 more ERROR - Error while commiting the transaction -- 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

17 years, 1 month

10
21
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-234) add to maven repository (not jboss).

by chun ping wang (JIRA)

add to maven repository (not jboss). ------------------------------------- Key: HSEARCH-234 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-234 Project: Hibernate Search Issue Type: Improvement Reporter: chun ping wang is it possible to copy the jboss repository and move the dependecy toward main maven 2 repository. I kinda don't want to point to two different repository. -- 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

17 years, 1 month

3
4
0 / 0

[Hibernate-JIRA] Created: (HBX-893) "Can't create session factory" if any @NamedQuery annotations on entities have errors in them

by Joseph Marques (JIRA)

"Can't create session factory" if any @NamedQuery annotations on entities have errors in them --------------------------------------------------------------------------------------------- Key: HBX-893 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-893 Project: Hibernate Tools Type: Bug Versions: 3.2beta8 Reporter: Joseph Marques This seems to be a pretty big restriction - especially if you want to be able to cater to those that try to adopt Hibernate Tools part of the way through development, where some annotations may already have errors in them. Instead, it should be much more user-friendly to expand the session factory anyway, but just not load those entities - perhaps even marking them with a little red 'X' to indicate that the user needs to fix something in them. -- 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

17 years, 1 month

2
5
0 / 0

[Hibernate-JIRA] Created: (HBX-1047) Constructor uses the non generated properties even though Meta tag attribute="gen-property" value is set to "false".

by Sukirtha Joseph (JIRA)

Constructor uses the non generated properties even though Meta tag attribute="gen-property" value is set to "false". --------------------------------------------------------------------------------------------------------------------- Key: HBX-1047 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1047 Project: Hibernate Tools Issue Type: Bug Components: hbm2java Environment: Hibernate 3.0 Reporter: Sukirtha Joseph Constructor uses the non generated properties even though Meta tag attribute="gen-property" value is set to "false". Thus class compilation fails. -- 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

17 years, 1 month

3
10
0 / 0

[Hibernate-JIRA] Created: (BVAL-14) ValidatorImpl.expandGroupName() does not seem to expand recursively, this goes against the spec

by Emmanuel Bernard (JIRA)

ValidatorImpl.expandGroupName() does not seem to expand recursively, this goes against the spec ----------------------------------------------------------------------------------------------- Key: BVAL-14 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-14 Project: Bean Validation Issue Type: Bug Components: ri-general Reporter: Emmanuel Bernard Assignee: Hardy Ferentschik -- 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

17 years, 1 month

2
3
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues September 2008