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 <bb...@tpg.com.au> on 2004/01/10 04:38:34 UTC
OJB problems and maybe some fixes (2nd time around)
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
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: OJB problems and maybe some fixes (2nd time around)
Posted by Jakob Braeuchi <jb...@gmx.ch>.
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