db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mahler <thm...@web.de>
Subject Re: Questions and maybe some fixes
Date Tue, 13 Jan 2004 11:22:56 GMT
Hi Brendan,

thanks for reporting these problems and for sugessting solutions!

Brendan Boesen wrote:
> Hi All,
> I've been having some problems with OJB.  One of them has me perplexed  
> and the others I think I have tracked down but the solutions I think  
> require code fixes.
> Before I go on, I should just make it clear that I'm using the world's  
> simplest database mapping.  One table per class (except for one table  
> for a bunch of nested classes), with top-down arity-one  
> (unidirectional) relationships.  (ie: no weird table inheritance  
> strategies!  :-)
> When I retrieve an object using getCollectionByQuery, only the main  
> object gets retrieved and none of the other referenced objects are  
> retrieved.  (Of course, if I then do getObjectByIdentity, the object  
> gets retrieved in full).  I guess it makes a lot of sense for  
> getCollectionByQuery to work this way but is there any way to specify  
> that getCollectionByQuery retrieve complete objects?
> I have a simple list() method that just queries for all objects of a  
> particular type and then does a getObjectByIdentity call to retrieve  
> the object in full before putting it in a collection to return.  Most  
> of the time the list objects are fully-loaded but occasionally they are  
> only partially-populated.  By this, I mean the root object is fully  
> populated with all fields and references.  However, the next object(s)  
> down have their references correctly populated but all fields are null.  
>  Has anyone any ideas what might be going wrong here?  This one is a  
> bit of a show-stopper for me.

Mhh, getCollectionByQuery is expected to produce completely materialized 
objects. they should exactly look like objects materialized by 
getObjectByIdentity calls!
If this is not the case it's bug.

But I+m sure this is covered by our junit tests. So are you really sure 
that there are no problems with the settings of the auto-retrieve 
attributes of your reference- and collection-descriptors?

> The other issues are related to the use of Oracle 9i.  I've been having  
> trouble with both Oracle TIMESTAMP sql types and with translating java  
> Longs to Oracle NUMBERs.
> I did the obvious things: set up a database column of type TIMESTAMP,  
> use a java.util.Date for my Java objects and use a converter  
> (org.apache.ojb.broker.accesslayer.conversions.JavaDate2SqlTimestampFiel 
> dConversion) to convert backwards and forwards.  Unfortunately, my  
> milliseconds are getting chopped-off!  (No comments please!)
> I had to create my own converter which used oracle.sql.TIMESTAMP as the  
> type to pass onto the database.  Unfortunately, that then produced a  
> ClassCastException in the PreparedStatement.  It looks like for  
> TIMESTAMP instances, the OraclePreparedStatement class wants such  
> values to be set using setTIMESTAMP.  I got around this by extending  
> PlatformOracle9iImpl and adding a check for values of type TIMESTAMP.   
> This solved the problem.
> My suggestion to fix this problem is:
> 1. Create a new conversion class specific to Oracle TIMESTAMPs:  
> org.apache.ojb.broker.accesslayer.conversions.JavaDate2OracleTimestampFi 
> eldConversion
> 2. Change to PlatformOracle9iImpl to handle oracle.sql.TIMESTAMP  
> instances.

IMO the the change should go into PlatformOracle)iImpl.

> java.lang.Long and NUMBER
> I'm trying to use primitive longs for my object ids and I'm trying to  
> use NUMBER fields to store those values in the database.  (Does that  
> sound at all weird by the way?)  Unfortunately, it looks like there  
> needs to be another use of a specifc set method on  
> OraclePreparedStatement.  In this case setNUMBER needs to be called,  
> passing in a Long value.  That change was easy to make by modifying my  
> Platform subclass but then the code broke in StatementManager's  
> bindUpdate method.  Looking in that method, I see that Platform is used  
> to set certain objects in the statement but is not used for others.  I  
> changed the method to always use the Platform's setObjectForStatement  
> method and things seem to work fine.  (Is there any particular reason  
> why this method did not use m_platform. setObjectForStatement for  
> particular parts of the statement?)
> My suggestion to fix this problem is:
> 1. Modify PlatformOracle9iImpl to handle this case - I noticed longs  
> are partially handled but if the type is NUMBER, the if statments all  
> evaluate false and you end up calling ps.setObject (which throws a  
> ClassCastException).
> 2. Modify StatementManager's bindUpdate method to call m_platform.  
> setObjectForStatement for all statement set methods.

Again I think this is a change for the PlatformOracle9iImpl.

Brendan, If you post me a patched version of PlatformOracle9iImpl I'll 
add your fixes to the code base!

Thanks, Thomas

> Brendan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org

To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org

View raw message