You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Brendan Boesen <br...@hesageek.com.au> on 2004/01/09 11:25:19 UTC
Questions and maybe some fixes
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.
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
Re: Questions and maybe some fixes
Posted by Brendan Boesen <br...@hesageek.com.au>.
Thomas,
>
> 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?
>
I'll definitely have to look into this further. I must be doing
something wrong but my tests start running ok once I get rid of
object-cacheing and connection-pooling. Weird.
>
> Brendan, If you post me a patched version of PlatformOracle9iImpl I'll
> add your fixes to the code base!
>
Ok, thanks. It may be a little while in coming though.
Brendan
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Questions and maybe some fixes
Posted by Thomas Mahler <th...@web.de>.
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