hi werner,
> This is due to the keys returned from class
> org.apache.ojb.broker.metadata.ClassDescriptor (version 1.30)
> in method "getKeyValues"
> where values are converted to their SQL types in line 841.
> Since values here are set on the Java level, it is obviously wrong
> to use key values that have been converted to SQL-compatible values
> (ie. my PK is now a Long, etc.)
>
assertFkAssignement gets the keyValues without converting them into
sql-compatible values:
Object[] refPkValues = refCld.getKeyValues(ref, false); << false : dont'
convert (ClassDescriptor 1.41)
hth
jakob
----- Original Message -----
From: "Thomas Mahler" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Monday, November 18, 2002 7:16 AM
Subject: [Fwd: OJB Framework: Bugs and Questions]
>
>
> -------- Original Message --------
> Subject: OJB Framework: Bugs and Questions
> Date: Sun, 17 Nov 2002 21:34:38 -0000
> From: "Werner Schulz" <[EMAIL PROTECTED]>
> Reply-To: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
>
> Dear Thomas,
>
> Sorry to write in english, but in technical matters like this one, it
> just flows easier.
>
> We have started to use the OJB framework for a big J2EE application
> since it fits our needs best (not too complicated but with sufficient
> SQL-like features like programmatic queries) which other OR frameworks
> seem to lack. So I am quite happy about using OJB.
>
> However, I have come across some problems, mainly due to my (lack
> of)understanding of
> OJB, but in a few cases due to bugs.
>
> On a more fundamental level, I would like to understand the
> implications
> J2EE has on the use of OJB. The docs are still somewhat thin here.
> >From what you will see below, I've got J2EE and OJB running for some
> very simple stuff. But I haven't yet tested the core elements of J2EE
> (concurrency->threads and transactions) and OJB's behaviour.
>
> Just answers to some basic questions would help me a great deal:
> a) We are using the PersistenceBrokerFactory straight as in
> aBroker = PersistenceBrokerFactory
> .createPersistenceBroker( new PBKey("repository.xml") );
> since I can't seem to see a way to initiate it otherwise using Oracle's
> J2EE (EJB 1.1) 9iAS server. (The suggested Jboss setup just doesn't
> apply
> for us.)
> Any experience/reasons why this approach may be incorrect?
>
> b) If I call the broker factory several times in methods that are
> part of a J2EE transaction, will the rollback work correctly? I.e.,
> if I avoid any call to transactions via OJB, will my J2EE transactions
> work as expected?
>
>
> Two cases which I think are bugs:
>
> a) (can't find the class but somewhere) the OJB properties file is
> called in from
> the classpath and the string ".properties" is attached, then the
> resource
> is called in. I think the file extension must not be used when using a
> ResourceBundle to read properties since this is automatically attached.
>
> b) a more fundamental error occurs when handling 1:N associations.
> I am using my own class for primary/foreign keys. When a contained
> object
> in a collection is assigned the id of the containing object, OJB uses
> the
> type since it has converted the primary key(s) of the containing object
> already into the SQL type.
>
> Example: I have a List (id:PK,name:String) where PK is my own
> PrimaryKey class (I have also written a converter for this,
> it maps PK to BIGINT and vice versa).
>
> List contains entries, where an entry has the fields
> (id:PK, parentid:PK, name:String, ...)
>
> When storing the List object, I get an exception since OJB tries to
> set the parentid with a java.lang.Long value.
>
> I have identified the lines of code that are causing this:
> (OJB 0.9.7)
>
> In class
> org.apache.ojb.broker.singlevm.PersistenceBrokerImpl (version 1.58)
> in method "assertFkAssignment" (line 653) there is a call:
>
> fld.getPersistentField().set(obj, refPkValues[i]);
>
> Here the PK object "refPkValues[i]" has the wrong type (Long instead of
> PK).
>
> This is due to the keys returned from class
> org.apache.ojb.broker.metadata.ClassDescriptor (version 1.30)
> in method "getKeyValues"
> where values are converted to their SQL types in line 841.
> Since values here are set on the Java level, it is obviously wrong
> to use key values that have been converted to SQL-compatible values
> (ie. my PK is now a Long, etc.)
>
> I have not checked whether M:N associations are also affected by this.
> (I will soon find out since they coming soon.)
>
>
> A Suggestion beyond current OJB:
> I would like to see a more sophisticated approach when setting values.
>
> I don't like to expose default constructors when a proper object model
> would use constructor arguments when creating an object. Hence I would
> like to replace the setters with constructors that take arguments.
> One could place constructor instructions into the mapping file:
> <class-descriptor ...>
> <constructor>
> <field refid="1"/>
> <field refid="3"/>
> <field refid="4"/>
> <constructor>
> <field ..../>
> </class-descriptor>
>
> which means that field 1,3,4 should be set in the constructor but not
> necessarily later via setters. (Getters are required since one needs
> to store the fields somehow!)
>
> I am looking forward to hearing from you.
>
> Best regards,
>
> Werner
>
> Werner Schulz
> Cambridge, UK
>
> work: [EMAIL PROTECTED]
> home: [EMAIL PROTECTED]
>
>
>
>
>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
