-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 
Author Message
 Post subject: The isAssignable check within FilterImpl method setParameter
PostPosted: Mon Sep 07, 2009 1:08 pm 
Newbie

Joined: Mon Sep 07, 2009 12:38 pm
Posts: 1
We have a custom type that takes a java.util.Date on the nullSafeSet and returns a java.sql.Timestamp from the nullSafeGet. This allows us some flexibility in our entities to use java.util.Date for our fields instead of java.sql.Timestamp if the consumer so desires.

We have recently encountered some problems with this custom type when trying to set the parameter value as a java.util.Date when using Filters. Because the nullSafeGet returnes java.sql.Timestamp, we have the getReturnedClass() return java.sql.Timestamp. The following code in FilterImpl will not work with that setup.

Code:
public Filter setParameter(String name, Object value) throws IllegalArgumentException {
      ....
      if ( value != null && !type.getReturnedClass().isAssignableFrom( value.getClass() ) ) {
         throw new IllegalArgumentException( "Incorrect type for parameter [" + name + "]" );
      }
               ....


We end up with
Code:
java.sql.Timestamp.isAssignableFrom(java.util.Date)
which isn't true.
I'm wondering though if this check might be backwards? Since filters are used to populate parameters in queries it seems it would be more like a nullSafeSet as opposed to the nullSafeGet. The nullSafeSet can afford to be somewhat lenient in the type that is being accepted and allow super types to be accepted. Whereas the nullSafeGet would need to be more specific so that the lowest level of the inheritance hierarchy is specified so that it can be used on the entity if so desired.

I realize I'm looking at this from the perspective of a very targeted use case and there is ?possibly? some reason that the code needs to work this way. I just wanted to start the discussion in case this code would happen to be incorrect or unneeded and others ran into the same situation which we have run into.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.