db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <jbraeu...@gmx.ch>
Subject Re: OJB problems and maybe some fixes (2nd time around)
Date Sun, 11 Jan 2004 10:24:35 GMT
hi brendan,

Brendan wrote:
> Hi All,
> 
> (Apologies if this appears on the list twice.  My first one was from a  
> less reliable source and looks like it didn't go through.)
> 
> 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  

when you use auto-retrieve=true in the collection-descriptor, then these the 
relationships are populated, there's no need to loop over the objects.

another way to retrieve the references and collections (if auto-retrieve is 
false) is to use PersistenceBroker#retrieveAllReferences.

hth
jakob

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