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.
> 
> TIMESTAMP
> 
> 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


Mime
View raw message