[Hibernate-JIRA] Created: (HBX-1001) Open Mapping Diagram chokes on enums
by Luke Maurer (JIRA)
Open Mapping Diagram chokes on enums
------------------------------------
Key: HBX-1001
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1001
Project: Hibernate Tools
Issue Type: Bug
Affects Versions: 3.2.beta11
Environment: Hibernate 3.2.1, MySQL 5.0.45-Debian_1ubuntu3-log
Reporter: Luke Maurer
In the Hibernate Console perspective, right-clicking a class in the Configuration subtree of the Hibernate Configurations view and clicking Open Mapping Diagram gives an empty editor ("Error opening the editor.") if the class, or any class reachable from it by assocations or collections, has a property whose type is a JDK5 enum.
The error logged is "Unable to create editor ID org.jboss.tools.hibernate.ui.veditor.editors.visualeditor: Enum class not found"; the stack trace attached is:
java.lang.ClassNotFoundException: foo.bar.AnEnumType
at java.lang.ClassLoader.findClass(ClassLoader.java:358)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:429)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:369)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:357)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at org.hibernate.util.ReflectHelper.classForName(ReflectHelper.java:112)
at org.hibernate.type.EnumType.setParameterValues(EnumType.java:286)
at org.hibernate.type.TypeFactory.injectParameters(TypeFactory.java:339)
at org.hibernate.type.CustomType.<init>(CustomType.java:67)
at org.hibernate.type.TypeFactory.heuristicType(TypeFactory.java:245)
at org.hibernate.mapping.SimpleValue.getType(SimpleValue.java:260)
at org.hibernate.mapping.Property.getType(Property.java:50)
at org.jboss.tools.hibernate.ui.view.views.OrmModelImageVisitor.visitPersistentField(OrmModelImageVisitor.java:111)
at org.jboss.tools.hibernate.ui.view.views.OrmLabelProvider.getImage(OrmLabelProvider.java:58)
at org.jboss.tools.hibernate.ui.veditor.editors.parts.ShapeEditPart.createFigure(ShapeEditPart.java:72)
at org.eclipse.gef.editparts.AbstractGraphicalEditPart.getFigure(AbstractGraphicalEditPart.java:445)
at org.eclipse.gef.editparts.AbstractGraphicalEditPart.addChildVisual(AbstractGraphicalEditPart.java:197)
at org.eclipse.gef.editparts.AbstractEditPart.addChild(AbstractEditPart.java:197)
at org.eclipse.gef.editparts.AbstractEditPart.refreshChildren(AbstractEditPart.java:727)
at org.eclipse.gef.editparts.AbstractEditPart.refresh(AbstractEditPart.java:677)
at org.eclipse.gef.editparts.AbstractGraphicalEditPart.refresh(AbstractGraphicalEditPart.java:564)
at org.eclipse.gef.editparts.AbstractEditPart.addNotify(AbstractEditPart.java:235)
at org.eclipse.gef.editparts.AbstractGraphicalEditPart.addNotify(AbstractGraphicalEditPart.java:212)
at org.jboss.tools.hibernate.ui.veditor.editors.parts.OrmShapeEditPart.addNotify(OrmShapeEditPart.java:44)
at org.eclipse.gef.editparts.AbstractEditPart.addChild(AbstractEditPart.java:198)
at org.eclipse.gef.editparts.AbstractEditPart.refreshChildren(AbstractEditPart.java:727)
at org.eclipse.gef.editparts.AbstractEditPart.refresh(AbstractEditPart.java:677)
at org.eclipse.gef.editparts.AbstractGraphicalEditPart.refresh(AbstractGraphicalEditPart.java:564)
at org.eclipse.gef.editparts.AbstractEditPart.addNotify(AbstractEditPart.java:235)
at org.eclipse.gef.editparts.AbstractGraphicalEditPart.addNotify(AbstractGraphicalEditPart.java:212)
at org.eclipse.gef.editparts.AbstractEditPart.addChild(AbstractEditPart.java:198)
at org.eclipse.gef.editparts.SimpleRootEditPart.setContents(SimpleRootEditPart.java:101)
at org.eclipse.gef.ui.parts.AbstractEditPartViewer.setContents(AbstractEditPartViewer.java:601)
at org.eclipse.gef.ui.parts.AbstractEditPartViewer.setContents(AbstractEditPartViewer.java:610)
at org.jboss.tools.hibernate.ui.veditor.editors.VisualEditor.initializeGraphicalViewer(VisualEditor.java:56)
at org.eclipse.gef.ui.parts.GraphicalEditor.createGraphicalViewer(GraphicalEditor.java:153)
at org.eclipse.gef.ui.parts.GraphicalEditor.createPartControl(GraphicalEditor.java:163)
at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:661)
at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:426)
at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:592)
at org.eclipse.ui.internal.EditorReference.getEditor(EditorReference.java:263)
at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2739)
at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2651)
at org.eclipse.ui.internal.WorkbenchPage.access$13(WorkbenchPage.java:2643)
at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2595)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2590)
at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2574)
at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2557)
at org.eclipse.ui.ide.IDE.openEditor(IDE.java:433)
at org.jboss.tools.hibernate.ui.view.views.OpenDiagramActionDelegate.run(OpenDiagramActionDelegate.java:51)
at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:256)
at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:546)
at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:490)
at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:402)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1101)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3319)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2971)
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.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:169)
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(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:508)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:447)
at org.eclipse.equinox.launcher.Main.run(Main.java:1173)
Session Data:
eclipse.buildId=I20070625-1500
java.version=1.6.0
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US
Command-line arguments: -os linux -ws gtk -arch x86
--
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
[Hibernate-JIRA] Commented: (HHH-1364) Defensive check of isClosed when obtaining a connection from ConnectionManager
by Gonzalo Vasquez (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1364?page=c... ]
Gonzalo Vasquez commented on HHH-1364:
--------------------------------------
Regarding:
"And as for non-cleared ThreadLocal-bound Sessions, this is the behavior I'd want to see anyway since it indicates problems in your thread cleanup code."
Ok, I might have problems in my cleanup code, but how do I identify them? In my particular case, the WebContainer (WAS 6) is the one which is "killing" unfinished threads when I make hot-updates of the deployed EAR. When resuming application operation, ConnectionManager doesn't come up gracefully, reporting the "connection manager has been closed" message.
Any comments appreciated
> Defensive check of isClosed when obtaining a connection from ConnectionManager
> ------------------------------------------------------------------------------
>
> Key: HHH-1364
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1364
> Project: Hibernate3
> Issue Type: Improvement
> Components: core
> Affects Versions: 3.1
> Environment: Particularly bad in J2EE environments, where thread stale thread-local connections show up in an unpredictable manner as threads are re-used.
> Reporter: Damon Feldman
> Assignee: Steve Ebersole
> Priority: Minor
> Fix For: 3.1.2
>
> Original Estimate: 20 minutes
> Remaining Estimate: 20 minutes
>
> A null connection is returned to the caller, causing a NPE in another part of the system if a connection is set to null AND the ConnectionManager is closed.
> ---- EXISTING CODE from ConnectionManager ----
> /**
> * Retrieves the connection currently managed by this ConnectionManager.
> * <p/>
> * Note, that we may need to obtain a connection to return here if a
> * connection has either not yet been obtained (non-UserSuppliedConnectionProvider)
> * or has previously been aggressively released (if supported in this environment).
> *
> * @return The current Connection.
> *
> * @throws HibernateException Indicates a connection is currently not
> * available (we are currently manually disconnected).
> */
> public Connection getConnection() throws HibernateException {
> if ( connection == null && !isClosed ) {
> openConnection();
> }
> return connection;
> }
> --------------------- RECOMMENDATION -----------
> public Connection getConnection() throws HibernateException {
> if ( connection == null) {
> if(isClosed )
> throw new HibernateException("A Connection Manager that has been closed cannot supply a Connection.");
> openConnection();
> }
> return connection;
> }
--
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
[Hibernate-JIRA] Updated: (HHH-952) Patch to allow subqueries with joins using Criteria API and Subqueries with DetachedCriteria
by Gail Badner (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-952?page=co... ]
Gail Badner updated HHH-952:
----------------------------
Fix Version/s: 3.2.6
> Patch to allow subqueries with joins using Criteria API and Subqueries with DetachedCriteria
> --------------------------------------------------------------------------------------------
>
> Key: HHH-952
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-952
> Project: Hibernate3
> Issue Type: Patch
> Components: core
> Affects Versions: 3.1 beta 1, 3.1 beta 2
> Environment: 3.1beta1 with MS SQL 2000 via jTDS
> Reporter: John
> Assignee: Gail Badner
> Priority: Critical
> Fix For: 3.2.6, 3.3
>
> Attachments: subquery-patch-3.2.4.SP1.txt, subquery-patch-311.txt, subquery-patch-313.txt, subquery-patch-31beta3.txt, subquery-patch.txt, subquery-patch.txt, SubqueryExpression.java
>
>
> The existing code in SubqueryExpression.java constructed a select statement but did not have any provisions for creating joins. Therefore, it was not possible using the criteria API to create an exists subselect that had a join, even though running the source DetachedCriteria alone works perfectly.
> For example, if this is the goal:
> select * from foo f
> where exists (select id from bar b join other o on b.o_id = o.id where o.prop = '123' and b.foo_id = f.id)
> One might try something like this:
> Criteria crit = session.createCriteria(Foo.class, fooAlias);
> DetachedCriteria barCrit = DetachedCriteria.forClass(Bar.class, barAlias);
> DetachedCriteria otherCrit = barCrit.createCriteria(Bar.OTHER_JOIN);
> otherCrit.add( Restrictions.eq(Other.PROP, "123") );
> barCrit.add( Restrictions.eqProperty( -- props to join to foo here --) );
> barCrit.setProjection( Projections.id() );
> crit.add( Subqueries.exists(barCrit) );
> However, the existing code generates something like the following, which gets an error with an unknown alias 'o':
> select * from foo f
> where exists (select id from bar b where o.prop = '123' and b.foo_id = f.id)
> This is also described here (at the end): http://forum.hibernate.org/viewtopic.php?t=942488
> The patch to SubqueryExpression.java fixes this to included the joins necessary for the filtering. This code was modeled (copied) off of code from CriteriaLoader. For me this works perfectly, but I don't understand the internals of this stuff enough to say how robust it is. Also included is a patch to the test case to enable testing of this, which was present but commented out. I did not change the contents of the test, which currently only attempts a joined subquery. This used to fail with an error, but now it works. The test does not check the results at all. (Inconsequential to the patch - Enrollment has two Ls.)
> -----side notes
> The patch file also has two other patches. The first increases the delay in BulkManipulationTest because I was getting inconsistent test results. I think that the precision on the version timestamp is not enough for 300 milliseconds delay to be enough to guarantee the test results. Also, in build.xml, there was a line that was meant to exclude the performance tests, but there was no **/*, on *, so they actually were not excluded. I changed this so the tests would complete in a reasonable amount of time. However, there is one other issue with testing that I worked around manually. After each test run, two databases (Users and Email) were left in the database. If I did not manually delete these then the number of failures on the next test run was different. This was really confusing until I figured it out because I was trying to make sure all the other testcases still passed with my patch, but even without the patch I was getting different results.
--
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
[Hibernate-JIRA] Reopened: (HHH-952) Patch to allow subqueries with joins using Criteria API and Subqueries with DetachedCriteria
by Gail Badner (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-952?page=co... ]
Gail Badner reopened HHH-952:
-----------------------------
Assignee: Gail Badner (was: Chris Bredesen)
> Patch to allow subqueries with joins using Criteria API and Subqueries with DetachedCriteria
> --------------------------------------------------------------------------------------------
>
> Key: HHH-952
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-952
> Project: Hibernate3
> Issue Type: Patch
> Components: core
> Affects Versions: 3.1 beta 1, 3.1 beta 2
> Environment: 3.1beta1 with MS SQL 2000 via jTDS
> Reporter: John
> Assignee: Gail Badner
> Priority: Critical
> Fix For: 3.3
>
> Attachments: subquery-patch-3.2.4.SP1.txt, subquery-patch-311.txt, subquery-patch-313.txt, subquery-patch-31beta3.txt, subquery-patch.txt, subquery-patch.txt, SubqueryExpression.java
>
>
> The existing code in SubqueryExpression.java constructed a select statement but did not have any provisions for creating joins. Therefore, it was not possible using the criteria API to create an exists subselect that had a join, even though running the source DetachedCriteria alone works perfectly.
> For example, if this is the goal:
> select * from foo f
> where exists (select id from bar b join other o on b.o_id = o.id where o.prop = '123' and b.foo_id = f.id)
> One might try something like this:
> Criteria crit = session.createCriteria(Foo.class, fooAlias);
> DetachedCriteria barCrit = DetachedCriteria.forClass(Bar.class, barAlias);
> DetachedCriteria otherCrit = barCrit.createCriteria(Bar.OTHER_JOIN);
> otherCrit.add( Restrictions.eq(Other.PROP, "123") );
> barCrit.add( Restrictions.eqProperty( -- props to join to foo here --) );
> barCrit.setProjection( Projections.id() );
> crit.add( Subqueries.exists(barCrit) );
> However, the existing code generates something like the following, which gets an error with an unknown alias 'o':
> select * from foo f
> where exists (select id from bar b where o.prop = '123' and b.foo_id = f.id)
> This is also described here (at the end): http://forum.hibernate.org/viewtopic.php?t=942488
> The patch to SubqueryExpression.java fixes this to included the joins necessary for the filtering. This code was modeled (copied) off of code from CriteriaLoader. For me this works perfectly, but I don't understand the internals of this stuff enough to say how robust it is. Also included is a patch to the test case to enable testing of this, which was present but commented out. I did not change the contents of the test, which currently only attempts a joined subquery. This used to fail with an error, but now it works. The test does not check the results at all. (Inconsequential to the patch - Enrollment has two Ls.)
> -----side notes
> The patch file also has two other patches. The first increases the delay in BulkManipulationTest because I was getting inconsistent test results. I think that the precision on the version timestamp is not enough for 300 milliseconds delay to be enough to guarantee the test results. Also, in build.xml, there was a line that was meant to exclude the performance tests, but there was no **/*, on *, so they actually were not excluded. I changed this so the tests would complete in a reasonable amount of time. However, there is one other issue with testing that I worked around manually. After each test run, two databases (Users and Email) were left in the database. If I did not manually delete these then the number of failures on the next test run was different. This was really confusing until I figured it out because I was trying to make sure all the other testcases still passed with my patch, but even without the patch I was getting different results.
--
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
[Hibernate-JIRA] Created: (HHH-2902) parameterList and indexed parameters using concurrently
by Vladimir A. Balandin (JIRA)
parameterList and indexed parameters using concurrently
-------------------------------------------------------
Key: HHH-2902
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2902
Project: Hibernate3
Issue Type: Bug
Components: query-sql
Affects Versions: 3.0 rc 1
Environment: Database: Oracle
Reporter: Vladimir A. Balandin
Query query = entityManager.getSession().createSQLQuery("SELECT * FROM items WHERE id IN (:ids) AND date>=? AND id IN (:ids2) ");
query.setParameterList("ids", new Integer[]{1,2,3});
query.setDate(0,Calendar.getInstance().getTime());
query.setParameterList("ids2", new Integer[]{1,2,3});
don't work with ora-00932 error, but following code work properly:
Query query = entityManager.getSession().createSQLQuery("SELECT * FROM items WHERE date>=? AND id IN (:ids) AND id IN (:ids2) ");
query.setDate(0,Calendar.getInstance().getTime());
query.setParameterList("ids", new Integer[]{1,2,3});
query.setParameterList("ids2", new Integer[]{1,2,3});
--
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
[Hibernate-JIRA] Created: (HHH-2904) Property-ref Child association has a null session on fetch
by kumar_j2ee (JIRA)
Property-ref Child association has a null session on fetch
----------------------------------------------------------
Key: HHH-2904
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2904
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.1.3
Environment: Hibernate Version: 3.1.3
Database: Oracle 10g,
Dialect: Oracle9Dialect
Reporter: kumar_j2ee
Priority: Blocker
Database Type: Legacy database with no single primary key foreign-key relationship. Also has all sorts of funky natural-business-keys, and we are trying our best to bend hibernate to retrofit for this database.
Very well given the back ground, here is what I have...
ObjectA has many ObjectB
ObjectB has many ObjectC.
ObjectA has a Composite-id combining 4 keys on the table.
ObjectB has a Composite-id combining all parents keys plus additional 2 keys.
ObjectC has a Composite-id combining subset of parents keys and additional 2 more keys.
Since the parents keys donot flow to the children as Foreign-key am forced to use a property-ref. So I ended up declaring a property-ref on ObjectB that matches the ObjectC unique key and mapped the ObjectC as a bag (one-to-many) on ObjectB.
Scenario;
I have to access ObjectA then get ObjectB from ObjectA and get ObjectC from ObjectB.
When I try fetching the association I get an error indicating the session is null with LazyInitializationException. I have a open session, its got nothing to do with hibernate transaction manager, am running my junits. The same works when the association in only one level deep for example I load ObjectB from database directly and then load ObjectC from ObjectB.
Session is open all the time.
I tried using Bag Sql Loader using Query-ref that brought in additional issues indicating "Not all parameters on the named query is set" Digging through the hibernate code I realized its treating the composite id as one named attribute
[i]
org.hibernate.impl.AbstractQueryImpl.java
protected void verifyParameters(boolean reserveFirstParameter) throws HibernateException {
if ( parameterMetadata.getNamedParameterNames().size() != namedParameters.size() + namedParameterLists.size() ) {
Set missingParams = new HashSet( parameterMetadata.getNamedParameterNames() );
missingParams.removeAll( namedParameterLists.keySet() );
missingParams.removeAll( namedParameters.keySet() );
throw new QueryException( "Not all named parameters have been set: " + missingParams, getQueryString() );
}
[/i]
getNamedParameterNames().size is returning back as 6 where as
namedParameters.size() returns back as 1.
If I try removing all the named parameters totally and tried loading the association... I started getting ...
[i]
public Query setParameter(int position, Object val, Type type) {
if ( parameterMetadata.getOrdinalParameterCount() == 0 ) {
throw new IllegalArgumentException("No positional parameters in query: " + getQueryString() );
}
[/i]
I tried multiple options one even with filter-def/ filter and realized Filter is not working for bags.
Can somebody help me understand if am doing something stupid. Or if this is a limitation and if there is any acceptable workaround.[color=blue][/color]
--
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
[Hibernate-JIRA] Created: (HHH-2906) Public access to meta-values in MetaType
by Jens Bruhn (JIRA)
Public access to meta-values in MetaType
----------------------------------------
Key: HHH-2906
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2906
Project: Hibernate3
Issue Type: Improvement
Components: metamodel
Affects Versions: 3.2.5
Environment: w2k, hibernate 3.2.5, postgres
Reporter: Jens Bruhn
Priority: Minor
I need public access to the meta-keys and values in the MetaType class. I know, that i can receive these values from the "Any" class, but i need static access without having an object of "Any" type.
Cause: I want to query, where a specific object is used. I can go through the configuration informations to see in which properties this object could be used. It works fine for all entitiy properties. But in some cases i have to use "Any" type. In the xml file i have MetaValues, which classes are allowed in this "Any" type. But i don't have access to these infos without querying one of those any objects. But i don't want to query if i don't have to... So it would be useful to make these infos public in MetaType.
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
17 years