Re: [hibernate-dev] SessionImpl.list(CriteriaImpl criteria) returns an empty list when no implementors exist
by C_Kevin Butterly
Hi,
I have previously run into the same issue numerous times. In all cases I was executing a criteria search without having mapped the particular entities, they were all simple mappings with no deemed dependencies on polymorphism. I agree that there should be some indicator to the fact that I had an omission in my mapping configuration. I like the idea of an exception being thrown, as its not obvious at the moment what the problem is.
Regards
Kevin
13 years, 1 month
hibernate-core 3.6 branch on GitHub
by Steve Ebersole
After the 4.0.0.Alpha1 release on Wednesday I want to rename the module
directories on the 3.6 branch to match what we did on master to make porting
fixes easier. This would mess up anyone with pending changes aganst 3.6
though, so I wanted to give everyone a heads up here.
Let me know if this timeline is an issue for anyone.
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
13 years, 1 month
hibernate-infinispan tests
by Steve Ebersole
There are currently a bunch of test failures in hibernate-infinispan. Are
these expected? I thought they were related to my changes, but i verified
that these failures are there even on master.
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
13 years, 1 month
Re: [hibernate-dev] SessionImpl.list(CriteriaImpl criteria) returns an empty list when no implementors exist
by Bruno Bieth
@Steve Ebersole
Hi Steve,
I came across the same problem regarding the SessionImpl.list returning an
empty list, and I ended up on this thread. I don't really understand your
reasoning here :
In other words the thing from which you query does not have to be mapped,
and we will instead query from all entity
class which implement the named interface or extend from the named class
('from java.lang.Object' and 'from java.lang.Comparable' are both valid
queries).
I get that we need to be able to return implementors for classes that are
not mapped (to support polymorphic queries). But it doesn't mean that we
can't fail when no implementors are found, does it ?
What would be the implications of throwing an exception when SessionImpl
cannot find any implementors for a given query ?
Consider the following code :
*
public List list(CriteriaImpl criteria) throws HibernateException {
errorIfClosed();
checkTransactionSynchStatus();
String[] implementors = factory.getImplementors(
criteria.getEntityOrClassName() );
int size = implementors.length;
if( size == 0 ) {
throw new IllegalStateException("no mapping found for class
..")
}
// ....*
Performing a search on Object.class would still work (given that we've got
at least a class mapped and registered) ?
Regards,
Bruno Bieth
13 years, 1 month
HV - Follow-Up: meta data API for method constraints
by Gunnar Morling
Hi,
I pretty much finished the implementation of the meta data API related to
method level constraints for Hibernate Validator (see
https://github.com/gunnarmorling/hibernate-validator/commits/HV-371). The
implementation conforms with what we currently discussed, but right now I'm
wondering whether exposing java.lang.reflect.Method on the API is actually a
good idea. I see two issues:
* Retrieving method objects via the reflection APIs is somewhat nasty, in
particular it requires to handle a checked NoSuchMethodException:
try {
Method bar = Foo.class.getDeclaredMethod( "bar", String.class );
}
catch(Exception e) {
throw new RuntimeException(e);
}
* The handling in inheritance hierarchies with overridden/implemented
methods can be confusing to users not overly familiar with the reflection
API. In particular there are different method objects for a base method and
its implementation/overriding methods. This can be irritating when invoking
MethodDescriptor#getMethod() for instance.
Therefore I would be interested in feedback on the following change:
public interface TypeDescriptor extends ElementDescriptor {
MethodDescriptor getConstraintsForMethod(String name, Class<?>...
parameterTypes);
//instead of MethodDescriptor getConstraintsForMethod(Method method);
...
}
public interface MethodDescriptor extends ElementDescriptor {
String getName();
List<Class<?>> parameterTypes();
//instead of Method getMethod()
...
}
WDYT?
Thanks, Gunnar
13 years, 1 month
