objectbridge-users — general list for all users of OJB. Questions, help requests etc. go here

Re: [ojb-users] bindSelect() Error in setObject() call...

[Thomas M. <tho...@ho...>]

Hi Corey,

Corey Klaasmeyer wrote:

 > I'm getting the following error when I try to write a new object to the
 > database:
 >
 > [DEFAULT] ERROR: bindSelect failed for:
 > com.klaasmeyer.forefront.om.ec.EcMeterReading{CMK,04172002,1725}, PK: 0,
 > value: CMK
 > Job setObject failed Driver not capable.
 >
 > 	at ojb.broker.accesslayer.JdbcAccess.materializeObject(Unknown
 > Source)
 > 	at ojb.broker.singlevm.PersistenceBrokerImpl.store(Unknown Source)
 > 	at
 > 
com.klaasmeyer.forefront.om.test.TestEquipmentCost.<init>(TestEquipmentCost.
 > java:67)
 > 	at
 > 
com.klaasmeyer.forefront.om.test.TestEquipmentCost.main(TestEquipmentCost.ja
 > va:95)
 > Process terminated with exit code 0
 >
 > Is this a driver issue? Any clues would be appreciated.
 >


Yes this is clearly a driver related issue.
Parameter binding is a common place for problems with all kind of drivers.
in the method ojb.broker.accesslayer.StatementManager.bindUpdate(...)
we solved this by delegating the binding to a Driver specific
Platform. The exact behaviour is thus delegated to a Driver specific class.

For ojb.broker.accesslayer.StatementManager.bindSelect(...), that causes
the problem in your case, this is not yet implemented, but could be
refactored quite easily.

But: I don't have access to your Jdbc driver. SO try to fix this bug on
your own, send in the patch, an we will refactor the Platform interface
to work for bindSelect(...) too.



 > Corey
 >
 > -----Original Message-----
 > From: Corey Klaasmeyer [mailto:Co...@kl...]
 > Sent: Wednesday, April 17, 2002 8:51 AM
 > To: 'Obj...@li...'
 > Subject: [ojb-users] Modifications to Work Around Lame ODBC Drivers...
 >
 >
 > Since I am working with a legacy ODBC driver from Simba, I have had 
to work
 > around exceptions which propogate up from that level. It would be 
great if I
 > could get some feedback on the implications of these changes -- all in
 > accesslayer.
 >
 > 1.) In ConnectionFactoryDefaultImpl, I commented out
 > conn.setAutoCommit(!broker.isInTransaction()).
 >


That's OK. In fact this been moved to the
PlatFormDefaultImpl.initializeJdbcConnection(...) method to allow
different behaviour for certain Platforms.
It's already in CVS !


 > I'm assuming autocommit can remain in its default state of true if
 > transactions are not being used.
 >


ACK


 > 2.) In StatementsForClass I commented out
 > result.setEscapeProcessing(ESCAPEPROCESSING);
 >



With my latest changes it is also possible to set the ESCAPEPROCESSING
   value at runtime from a PlatformImpl. Thus it won't be necessary to
comment out anything....


We just need a PlatformSimbaImpl doing all the special Simba things...

cu,

Thomas


 > It doesn't look like this should have any effect. This is the javadoc for
 > setEscapeProcessing():
 > Sets escape processing on or off. If escape scanning is on (the default),
 > the driver will do escape substitution before sending the SQL 
statement to
 > the database. Note: Since prepared statements have usually been 
parsed prior
 > to making this call, disabling escape processing for PreparedStatements
 > objects will have no effect.
 >
 > Finally, these are obviously not general solutions. I think you will 
need to
 > catch exceptions and react in some rational way. This may be a better 
mail
 > for the developers list...
 >
 > With these changes, OJB is now reading some simple records from our
 > lumbering accounting system.
 >
 > Corey
 >
 >
 >
 > _______________________________________________
 > Objectbridge-users mailing list
 > Obj...@li...
 > https://lists.sourceforge.net/lists/listinfo/objectbridge-users
 >
 > _______________________________________________
 > Objectbridge-users mailing list
 > Obj...@li...
 > https://lists.sourceforge.net/lists/listinfo/objectbridge-users
 >
 >
 >
 >

Re: [ojb-users] n:m-mapping

[Thomas M. <tho...@ho...>]

Hi Juergen,

Juergen Lippold wrote:

 > Hello,
 >
 > im Tutorial 3 sind  diese Collection Descriptoren angegeben.
 > Wof=FCr steht <inverse_fk_descriptor_ids>999</inverse_fk_descriptor_id=
s>
 > Wohin verweist die 999?
 >
 > In the Tutorial there is an exaple for n:m-mappings with the=20
following Descriptors.
 > But what for is the entry=20
<inverse_fk_descriptor_ids>999</inverse_fk_descriptor_ids>
 > specially what does 999 mean?
 >


That's one of the "dark spots" on the repository.dtd. It just means "no
descriptor at all" but the parser requires to have an int in this place.


I hope to provide a polished version of the repository.dtd soon. Please
ignore this 999 for the time being.

Thomas


 >
 > <ClassDescriptor id=3D"1">
 >       <class.name>test.ojb.broker.Person</class.name>
 > ...
 > <CollectionDescriptor id=3D"2">
 >          <cdfield.name>projects</cdfield.name>
 >          <items.class>test.ojb.broker.Project</items.class>
 >          <inverse_fk_descriptor_ids>999</inverse_fk_descriptor_ids>
 >          <indirection_table>PERSON_PROJECT</indirection_table>
 >=20
<fks_pointing_to_this_class>PERSON_ID</fks_pointing_to_this_class>
 >=20
<fks_pointing_to_items_class>PROJECT_ID</fks_pointing_to_items_class>
 >          <auto.retrieve>true</auto.retrieve>
 >          <auto.update>true</auto.update>
 > </CollectionDescriptor>
 > ..
 > </ClassDescriptor>
 >
 > <ClassDescriptor id=3D"1">
 >       <class.name>test.ojb.broker.Project</class.name>
 > ...
 >   <CollectionDescriptor id=3D"2">
 >          <cdfield.name>persons</cdfield.name>
 >          <items.class>test.ojb.broker.Person</items.class>
 >          <inverse_fk_descriptor_ids>999</inverse_fk_descriptor_ids>
 >          <indirection_table>PERSON_PROJECT</indirection_table>
 >=20
<fks_pointing_to_this_class>PROJECT_ID</fks_pointing_to_this_class>
 >=20
<fks_pointing_to_items_class>PERSON_ID</fks_pointing_to_items_class>
 >          <auto.retrieve>true</auto.retrieve>
 >          <auto.update>true</auto.update>
 >       </CollectionDescriptor>
 >  </ClassDescriptor>
 >
 > Thank for answering
 >
 > Juergen Lippold
 >
 >
 >
 > _______________________________________________
 > Objectbridge-users mailing list
 > Obj...@li...
 > https://lists.sourceforge.net/lists/listinfo/objectbridge-users
 >
 >
 >
 >

[ojb-users] bindSelect() Error in setObject() call...

[Corey K. <Co...@kl...>]

I'm getting the following error when I try to write a new object to the
database:

[DEFAULT] ERROR: bindSelect failed for:
com.klaasmeyer.forefront.om.ec.EcMeterReading{CMK,04172002,1725}, PK: 0,
value: CMK
Job setObject failed Driver not capable.

	at ojb.broker.accesslayer.JdbcAccess.materializeObject(Unknown
Source)
	at ojb.broker.singlevm.PersistenceBrokerImpl.store(Unknown Source)
	at
com.klaasmeyer.forefront.om.test.TestEquipmentCost.<init>(TestEquipmentCost.
java:67)
	at
com.klaasmeyer.forefront.om.test.TestEquipmentCost.main(TestEquipmentCost.ja
va:95)
Process terminated with exit code 0

Is this a driver issue? Any clues would be appreciated.

Corey

-----Original Message-----
From: Corey Klaasmeyer [mailto:Co...@kl...]
Sent: Wednesday, April 17, 2002 8:51 AM
To: 'Obj...@li...'
Subject: [ojb-users] Modifications to Work Around Lame ODBC Drivers...


Since I am working with a legacy ODBC driver from Simba, I have had to work
around exceptions which propogate up from that level. It would be great if I
could get some feedback on the implications of these changes -- all in
accesslayer.

1.) In ConnectionFactoryDefaultImpl, I commented out
conn.setAutoCommit(!broker.isInTransaction()).

I'm assuming autocommit can remain in its default state of true if
transactions are not being used.

2.) In StatementsForClass I commented out
result.setEscapeProcessing(ESCAPEPROCESSING);

It doesn't look like this should have any effect. This is the javadoc for
setEscapeProcessing():
Sets escape processing on or off. If escape scanning is on (the default),
the driver will do escape substitution before sending the SQL statement to
the database. Note: Since prepared statements have usually been parsed prior
to making this call, disabling escape processing for PreparedStatements
objects will have no effect. 

Finally, these are obviously not general solutions. I think you will need to
catch exceptions and react in some rational way. This may be a better mail
for the developers list...

With these changes, OJB is now reading some simple records from our
lumbering accounting system.

Corey



_______________________________________________
Objectbridge-users mailing list
Obj...@li...
https://lists.sourceforge.net/lists/listinfo/objectbridge-users

[ojb-users] Modifications to Work Around Lame ODBC Drivers...

[Corey K. <Co...@kl...>]

Since I am working with a legacy ODBC driver from Simba, I have had to work
around exceptions which propogate up from that level. It would be great if I
could get some feedback on the implications of these changes -- all in
accesslayer.

1.) In ConnectionFactoryDefaultImpl, I commented out
conn.setAutoCommit(!broker.isInTransaction()).

I'm assuming autocommit can remain in its default state of true if
transactions are not being used.

2.) In StatementsForClass I commented out
result.setEscapeProcessing(ESCAPEPROCESSING);

It doesn't look like this should have any effect. This is the javadoc for
setEscapeProcessing():
Sets escape processing on or off. If escape scanning is on (the default),
the driver will do escape substitution before sending the SQL statement to
the database. Note: Since prepared statements have usually been parsed prior
to making this call, disabling escape processing for PreparedStatements
objects will have no effect. 

Finally, these are obviously not general solutions. I think you will need to
catch exceptions and react in some rational way. This may be a better mail
for the developers list...

With these changes, OJB is now reading some simple records from our
lumbering accounting system.

Corey

[ojb-users] n:m-mapping

[Juergen L. <jli...@un...>]

Hello,

im Tutorial 3 sind  diese Collection Descriptoren angegeben.
Wof=FCr steht <inverse_fk_descriptor_ids>999</inverse_fk_descriptor_ids>
Wohin verweist die 999?

In the Tutorial there is an exaple for n:m-mappings with the following =
Descriptors.
But what for is the entry <inverse_fk_descriptor_ids>999</inverse_fk_descri=
ptor_ids>
specially what does 999 mean?


<ClassDescriptor id=3D"1">
      <class.name>test.ojb.broker.Person</class.name>
...
<CollectionDescriptor id=3D"2">
         <cdfield.name>projects</cdfield.name>
         <items.class>test.ojb.broker.Project</items.class>
         <inverse_fk_descriptor_ids>999</inverse_fk_descriptor_ids>
         <indirection_table>PERSON_PROJECT</indirection_table>
         <fks_pointing_to_this_class>PERSON_ID</fks_pointing_to_this_class>=

         <fks_pointing_to_items_class>PROJECT_ID</fks_pointing_to_items_cla=
ss>
         <auto.retrieve>true</auto.retrieve>
         <auto.update>true</auto.update>
</CollectionDescriptor>
..
</ClassDescriptor>

<ClassDescriptor id=3D"1">
      <class.name>test.ojb.broker.Project</class.name>
...
  <CollectionDescriptor id=3D"2">
         <cdfield.name>persons</cdfield.name>
         <items.class>test.ojb.broker.Person</items.class>
         <inverse_fk_descriptor_ids>999</inverse_fk_descriptor_ids>
         <indirection_table>PERSON_PROJECT</indirection_table>
         <fks_pointing_to_this_class>PROJECT_ID</fks_pointing_to_this_class=
>
         <fks_pointing_to_items_class>PERSON_ID</fks_pointing_to_items_clas=
s>
         <auto.retrieve>true</auto.retrieve>
         <auto.update>true</auto.update>
      </CollectionDescriptor>
 </ClassDescriptor>

Thank for answering

Juergen Lippold

[ojb-users] reverse_db: "Driver not capable."

[Corey K. <Co...@kl...>]

Using reverse_db, I get a "Driver not capable" message when I try to
generate a schema from a database using the Sun driver. The message comes
from ODBC wrapper for the database, not the driver, and it looks like this: 

[reversedb] 0:[SimbaLNA][Simba][SimbaEngine ODBC Driver]Driver not capable. 

I'm assuming that there were un-implemented metadata functionality somewhere
in the ODBC implementation. Any clues where this might be failing? Perhaps,
exotic DatabaseMetaData methods? I will try to gather some more information
by running it in a debugger.

Corey

[ojb-users] Non-Decomposed N:M mappings and extents

[<Joa...@tp...>]

Hy,

I'm having a problem with non-decomposed N:M mappings (which seem to be the
source of quite some trouble) in combination with extents. I reduced it to
a simple Test case (I'll attach the repository_user.xml, the Java files and
the sql-script to create the DB (for MySQL) is available, when needed).
Basically I have one simple Class (called OneSide) that has a list of
ManySide objects. ManySide is an equally simple Class with an ID and a
value (String/VARCHAR). Additionally there is a class ManySideExtent that
extends ManySide and adds an additional attribute "anotherValue" (String as
well).

The Problem is that although the Code that handles M:N relations seems to
support extents it always breaks, 'cause it doesn't get the select
statement for the extended class correct (it fails to include the extended
class' table in the FROM-clause). The exception that is thrown is

General error: Unknown table 'manyside_extent' in field list
     at ojb.broker.accesslayer.JdbcAccess.executeQuery(JdbcAccess.java:199)
     at ojb.broker.accesslayer.RsIterator.<init>(RsIterator.java:361)
     at
ojb.broker.singlevm.PersistenceBrokerImpl.getIteratorFromQuery(PersistenceBrokerImpl.java:1100)
     at
ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:877)
     at
ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:937)
     at
ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:1013)
     at
ojb.broker.singlevm.PersistenceBrokerImpl.retrieveCollection(PersistenceBrokerImpl.java:582)
     at
ojb.broker.singlevm.PersistenceBrokerImpl.retrieveCollections(PersistenceBrokerImpl.java:626)
     at
ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(RsIterator.java:521)
     at ojb.broker.accesslayer.RsIterator.next(RsIterator.java:289)
     at
ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:880)
     at
ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:925)
     at
ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:1013)
     at
ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:1000)
     at
ojb.broker.singlevm.PersistenceBrokerImpl.getObjectByQuery(PersistenceBrokerImpl.java:1170)
     at Test.ojbReadTest(Test.java:50)
     at Test.main(Test.java:24)

This occures when using the PersistenceBroker directly as well as when
using ODMG (though with ODMG it already happens at write time, OJB only
breaks when you try to read the object).

anyone got any idea? Is it just simple mis-configuration? Am I beeing blind
for something obvious? Please Help!

regards
Joachim Sauer

[ojb-users] proxyReference=true --> type mismatch

[Pelzer, C. <Pe...@LA...>]

Hi there,

Here my first OJB-Question :-)

Switching the proxyReference in the repository.xml to 'true' always gives us
a 'field type mismatch'.

Exact log:
com.bla.container.MNUP:0000000000000008
[DEFAULT] ERROR: field type mismatch
java.lang.IllegalArgumentException: field type mismatch
        at java.lang.reflect.Field.set(Native Method)
        at
ojb.broker.metadata.PersistentFieldDefaultImpl.set(PersistentFieldDefaultImp
l.java:114)
        at
ojb.broker.singlevm.PersistenceBrokerImpl.retrieveReference(PersistenceBroke
rImpl.java:539)
        at
ojb.broker.singlevm.PersistenceBrokerImpl.retrieveReferences(PersistenceBrok
erImpl.java:510)
        at
ojb.broker.singlevm.PersistenceBrokerImpl.getDBObject(PersistenceBrokerImpl.
java:1100)
        at
ojb.broker.singlevm.PersistenceBrokerImpl.getObjectByIdentity(PersistenceBro
kerImpl.java:1181)
        at
ojb.broker.accesslayer.IndirectionHandler.materializeSubject(IndirectionHand
ler.java:202)
        at
ojb.broker.accesslayer.IndirectionHandler.getRealSubject(IndirectionHandler.
java:187)
        at
ojb.broker.accesslayer.IndirectionHandler.invoke(IndirectionHandler.java:159
)
        at $Proxy4.getId(Unknown Source)
        at menuModel, trying to get a value from one resultObject by
get-method "menuId = currentEntry.getId();"


It only works when we delete the proxyReference in MNUP and set the
class.proxy in FIRP to dynamic.

The MNUP-Class is defined in the repository.xml like this:
    <ClassDescriptor id="5">
        <class.name>com.bla.container.MNUP</class.name>
        <class.proxy>dynamic</class.proxy>
        <table.name>MNUP</table.name>
        <FieldDescriptor id="1">
            <field.name>m_id</field.name>
            <column.name>ID</column.name>
            <jdbc_type>CHAR</jdbc_type>
            <PrimaryKey>true</PrimaryKey>
        </FieldDescriptor>
.
.
.
        <ReferenceDescriptor id="2">
            <proxyReference>true</proxyReference>
            <rdfield.name>m_FIRP_MenueFirmId</rdfield.name>
            <referenced.class>com.bla.container.FIRP</referenced.class>
            <fk_descriptor_ids>11</fk_descriptor_ids>
        </ReferenceDescriptor>

The FIRP-Class is defined like this:
    <ClassDescriptor id="8">
        <class.name>com.bla.container.FIRP</class.name>
        <class.proxy>dynamic</class.proxy>
        <table.name>FIRP</table.name>
        <FieldDescriptor id="1">
            <field.name>m_id</field.name>
            <column.name>ID</column.name>
            <jdbc_type>CHAR</jdbc_type>
            <PrimaryKey>true</PrimaryKey>
        </FieldDescriptor>
.
.
.
        <CollectionDescriptor id="5">
            <proxyCollection>true</proxyCollection>
            <cdfield.name>m_collection_MNUP_MenueFirmId</cdfield.name>
            <items.class>com.bla.container.MNUP</items.class>
            <inverse_fk_descriptor_ids>11</inverse_fk_descriptor_ids>
        </CollectionDescriptor>



Hope these infos help understanding our problem... Any ideas?
Greets,
Chris

[ojb-users] 1:n mapping with 0 or null

[Juergen L. <jli...@un...>]

Hello,

I have gor a 1:n mapping with two objects a group and its persons
The group has a vector and the person hat an Interface and an long value =
for the groupId
Starting the program, createing users without a group everything is fine.
But if I stop the server and start it again. Then The Person has a =
reference to a group with Id 0
But this group dosn't exist, so there will be an error.

What can I do to solve the problem??

[ojb-users] 1.n mapping error with value 0

[Juergen L. <jli...@un...>]

Hallo,

ich habe ein 1:n mapping.=20
Eine Gruppe hat n-Mitarbeiter. Und ein Mitarbeiter geh=F6rt zu keiner oder =
einer Gruppe.
Wenn ich nun Mitarbeiter ohne Zuordnung zu einer Gruppe habe wird dies =
solange der Server l=E4uft korrekt gehandhabt.
Wenn ich den Server neu starte (new cache) wird versucht einem Mitarbeiter =
ohne Gruppenzuordung eine Gruppe mit id 0 zuzuordnen.
Was kann man daegen tun?

gru=DF J=FCrgen

Re: [ojb-users] NumberFormatException: null when calling PersistenceBrokerFactory .createPersistenceBroker

[Thomas M. <tho...@ho...>]

Hi Scott,

try to set the Log-Level for RepositoryXmlHandler to DEBUG:
ojb.broker.metadata.RepositoryXmlHandler=DEBUG

This will switch on tracing of the parse process of the repository and 
you can see in which element the crash happens.

hth,

Thomas

Weaver, Scott wrote:

> Any Ideas???
> 
> [BOOT] INFO: OJB.properties: file:/C:/Webapps/Apache Tomcat 
> 4.0/webapps/agora/WE
> B-INF/classes/OJB.properties
> [ojb.broker.metadata.RepositoryXmlHandler] ERROR: null
> java.lang.NumberFormatException: null
>         at java.lang.Integer.parseInt(Unknown Source)
>         at java.lang.Integer.parseInt(Unknown Source)
>         at 
> ojb.broker.metadata.RepositoryXmlHandler.startElement(RepositoryXmlHa
> ndler.java:192)
>         at com.sun.xml.parser.Parser.maybeElement(Parser.java:1391)
>         at com.sun.xml.parser.Parser.content(Parser.java:1499)
>         at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
>         at com.sun.xml.parser.Parser.content(Parser.java:1499)
>         at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
>         at com.sun.xml.parser.Parser.parseInternal(Parser.java:492)
>         at com.sun.xml.parser.Parser.parse(Parser.java:309)
>         at 
> ojb.broker.metadata.DescriptorRepository.buildRepository(DescriptorRe
> pository.java:222)
>         at 
> ojb.broker.metadata.DescriptorRepository.<init>(DescriptorRepository.
> java:191)
>         at 
> ojb.broker.metadata.DescriptorRepository.getInstance(DescriptorReposi
> tory.java:246)
>         at 
> ojb.broker.PersistenceBrokerFactory.createPersistenceBroker(Persisten
> ceBrokerFactory.java:142)
> 
> thanks,
> Scott
> 

[ojb-users] NumberFormatException: null when calling PersistenceBrokerFactory .createPersistenceBroker

[Weaver, S. <Sw...@ri...>]

Any Ideas???

[BOOT] INFO: OJB.properties: file:/C:/Webapps/Apache Tomcat
4.0/webapps/agora/WE
B-INF/classes/OJB.properties
[ojb.broker.metadata.RepositoryXmlHandler] ERROR: null
java.lang.NumberFormatException: null
        at java.lang.Integer.parseInt(Unknown Source)
        at java.lang.Integer.parseInt(Unknown Source)
        at
ojb.broker.metadata.RepositoryXmlHandler.startElement(RepositoryXmlHa
ndler.java:192)
        at com.sun.xml.parser.Parser.maybeElement(Parser.java:1391)
        at com.sun.xml.parser.Parser.content(Parser.java:1499)
        at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
        at com.sun.xml.parser.Parser.content(Parser.java:1499)
        at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
        at com.sun.xml.parser.Parser.parseInternal(Parser.java:492)
        at com.sun.xml.parser.Parser.parse(Parser.java:309)
        at
ojb.broker.metadata.DescriptorRepository.buildRepository(DescriptorRe
pository.java:222)
        at
ojb.broker.metadata.DescriptorRepository.<init>(DescriptorRepository.
java:191)
        at
ojb.broker.metadata.DescriptorRepository.getInstance(DescriptorReposi
tory.java:246)
        at
ojb.broker.PersistenceBrokerFactory.createPersistenceBroker(Persisten
ceBrokerFactory.java:142)

thanks,
Scott

[ojb-users] (no subject)

[<inf...@bo...>]

confirm 809431

[ojb-users] OJB Integration with Legacy Application and sun.jdbc.odbc.JdbcOdb cDriver, and Mapping Generation...

[Corey K. <Co...@kl...>]

I am writing an application which interfaces with a
legacy-construction-management-software application and I am exploring the
possibility of using OJB for object mapping. From what I can gather, I will
need to specify an default database for OJB's internal repository, and a
legacy,-application-database-connection descriptor for each class
descriptor, e.g.:

<ClassDescriptor>
  ...
  <JdbcConnectionDescriptor>...</JdbcConnectionDescriptor>
  ...
</ClassDescriptor>

Is this correct?

For a number of reasons, I cannot use the legacy application's underlying
database for these internal tables.

Also, are there any mapping -- class and repository -- generation tools in
the works?

FYI, I chose OJB over Castor, because it provides support for Sun's driver
because you were thoughtful enough to limit yourself to JDBC 1.0. I also
like the fact that there is a JDO implementation in the hopper.

Thanks,
Corey

AW: [ojb-users] ODMG Cascading Updates : possible/probable bug.

[Mahler T. <tho...@it...>]

Hi Charles,

> Hi Again,
> 
> Has anyone been able to have a quick look at this yet ? 

Not yet. I added it to my ever growing todo list...

> Either we're making
> an obvious and silly mistake, or there is a fundamental error 
> in the ODMG
> transaction code, which could have big consequences.
> 

I assume it's a OJB bug. Thus I really appreciate your contribution of a
complete testcase which will help to hunt it down.

cu,

Thomas

> Thanks,
> 
> Charles.
> 
> > -----Original Message-----
> > From: Charles Anthony [mailto:cha...@hp...]
> > Sent: 08 April 2002 13:18
> > To: 'obj...@li...'
> > Cc: 'tho...@it...'
> > Subject: [ojb-users] ODMG Cascading Updates : possible/probable bug.
> > 
> > 
> > Hello All,
> > 
> > In OJB-0.8.375, cascading updates appears to be broken when 
> > using ODMG.
> > 
> > A colleague and I have managed to abstract the problem into a 
> > simple test
> > case.
> > test.ClassA has a collection of test.ClassB
> > test.ClassB has a reference back to test.ClassA
> > i.e. a simple bi-directional 0..n relationship between ClassA 
> > and ClassB.
> > 
> > We create an instance of ClassA, and add an instance of 
> ClassB to the
> > classBs Collection; we then lock the instance of ClassA for 
> write, and
> > commit the transaction.
> > 
> > Extract :
> > ClassA a1 = new ClassA("A 1");
> > ClassB b1 = new ClassB("B 1");
> > a1.getClassBs().add(b1);
> > 
> > Transaction tx = null;
> > tx = odmg.newTransaction();
> > tx.begin();
> > tx.lock(a1, tx.WRITE);
> > tx.commit();
> > 
> > When the transaction is committed, the ClassA row is 
> > correctly inserted into
> > the database, and ClassB row is also inserted into the database.
> > Unfortunately, it is inserted twice, resulting in a Primary 
> > key violation
> > (I've remove the primary key constraint in the attatched SQL).
> > 
> > It is some time since I've been able to spend anytime on OJB, 
> > and so my
> > knowledge of its internals has faded somewhat. However, by 
> > stepping through
> > in debug, it seems that the the ClassB instance is committed 
> > twice, once in
> > the collection and once on it's own.
> > 
> > I attach the test case, the repository_user.xml and the SQL 
> > to create the
> > tables. We're using SQL Server, but I'm fairly sure this is 
> a platform
> > independent problem.
> > 
> > Are we doing something wrong, or is this a bug ?
> > 
> > Thanks,
> > 
> > Charles.
> > 
> > 
> > 
> > This email and any attachments are strictly confidential and 
> > are intended
> > solely for the addressee. If you are not the intended 
> > recipient you must
> > not disclose, forward, copy or take any action in reliance on 
> > this message
> > or its attachments. If you have received this email in error 
> > please notify
> > the sender as soon as possible and delete it from your 
> > computer systems.
> > Any views or opinions presented are solely those of the 
> > author and do not
> > necessarily reflect those of HPD Software Limited or its affiliates.
> > 
> >  At present the integrity of email across the internet cannot 
> > be guaranteed
> > and messages sent via this medium are potentially at risk.  
> > All liability
> > is excluded to the extent permitted by law for any claims 
> > arising as a re-
> > sult of the use of this medium to transmit information by or to 
> > HPD Software Limited or its affiliates.
> > 
> > 
> >           
> > 
> > 
> 
> 
> This email and any attachments are strictly confidential and 
> are intended
> solely for the addressee. If you are not the intended 
> recipient you must
> not disclose, forward, copy or take any action in reliance on 
> this message
> or its attachments. If you have received this email in error 
> please notify
> the sender as soon as possible and delete it from your 
> computer systems.
> Any views or opinions presented are solely those of the 
> author and do not
> necessarily reflect those of HPD Software Limited or its affiliates.
> 
>  At present the integrity of email across the internet cannot 
> be guaranteed
> and messages sent via this medium are potentially at risk.  
> All liability
> is excluded to the extent permitted by law for any claims 
> arising as a re-
> sult of the use of this medium to transmit information by or to 
> HPD Software Limited or its affiliates.
> 
> 

RE: [ojb-users] ODMG Cascading Updates : possible/probable bug.

[Charles A. <cha...@hp...>]

Hi Again,

Has anyone been able to have a quick look at this yet ? Either we're making
an obvious and silly mistake, or there is a fundamental error in the ODMG
transaction code, which could have big consequences.

Thanks,

Charles.

> -----Original Message-----
> From: Charles Anthony [mailto:cha...@hp...]
> Sent: 08 April 2002 13:18
> To: 'obj...@li...'
> Cc: 'tho...@it...'
> Subject: [ojb-users] ODMG Cascading Updates : possible/probable bug.
> 
> 
> Hello All,
> 
> In OJB-0.8.375, cascading updates appears to be broken when 
> using ODMG.
> 
> A colleague and I have managed to abstract the problem into a 
> simple test
> case.
> test.ClassA has a collection of test.ClassB
> test.ClassB has a reference back to test.ClassA
> i.e. a simple bi-directional 0..n relationship between ClassA 
> and ClassB.
> 
> We create an instance of ClassA, and add an instance of ClassB to the
> classBs Collection; we then lock the instance of ClassA for write, and
> commit the transaction.
> 
> Extract :
> ClassA a1 = new ClassA("A 1");
> ClassB b1 = new ClassB("B 1");
> a1.getClassBs().add(b1);
> 
> Transaction tx = null;
> tx = odmg.newTransaction();
> tx.begin();
> tx.lock(a1, tx.WRITE);
> tx.commit();
> 
> When the transaction is committed, the ClassA row is 
> correctly inserted into
> the database, and ClassB row is also inserted into the database.
> Unfortunately, it is inserted twice, resulting in a Primary 
> key violation
> (I've remove the primary key constraint in the attatched SQL).
> 
> It is some time since I've been able to spend anytime on OJB, 
> and so my
> knowledge of its internals has faded somewhat. However, by 
> stepping through
> in debug, it seems that the the ClassB instance is committed 
> twice, once in
> the collection and once on it's own.
> 
> I attach the test case, the repository_user.xml and the SQL 
> to create the
> tables. We're using SQL Server, but I'm fairly sure this is a platform
> independent problem.
> 
> Are we doing something wrong, or is this a bug ?
> 
> Thanks,
> 
> Charles.
> 
> 
> 
> This email and any attachments are strictly confidential and 
> are intended
> solely for the addressee. If you are not the intended 
> recipient you must
> not disclose, forward, copy or take any action in reliance on 
> this message
> or its attachments. If you have received this email in error 
> please notify
> the sender as soon as possible and delete it from your 
> computer systems.
> Any views or opinions presented are solely those of the 
> author and do not
> necessarily reflect those of HPD Software Limited or its affiliates.
> 
>  At present the integrity of email across the internet cannot 
> be guaranteed
> and messages sent via this medium are potentially at risk.  
> All liability
> is excluded to the extent permitted by law for any claims 
> arising as a re-
> sult of the use of this medium to transmit information by or to 
> HPD Software Limited or its affiliates.
> 
> 
>           
> 
> 


This email and any attachments are strictly confidential and are intended
solely for the addressee. If you are not the intended recipient you must
not disclose, forward, copy or take any action in reliance on this message
or its attachments. If you have received this email in error please notify
the sender as soon as possible and delete it from your computer systems.
Any views or opinions presented are solely those of the author and do not
necessarily reflect those of HPD Software Limited or its affiliates.

 At present the integrity of email across the internet cannot be guaranteed
and messages sent via this medium are potentially at risk.  All liability
is excluded to the extent permitted by law for any claims arising as a re-
sult of the use of this medium to transmit information by or to 
HPD Software Limited or its affiliates.

[ojb-users] ODMG Cascading Updates : possible/probable bug.

[Charles A. <cha...@hp...>]

Hello All,

In OJB-0.8.375, cascading updates appears to be broken when using ODMG.

A colleague and I have managed to abstract the problem into a simple test
case.
test.ClassA has a collection of test.ClassB
test.ClassB has a reference back to test.ClassA
i.e. a simple bi-directional 0..n relationship between ClassA and ClassB.

We create an instance of ClassA, and add an instance of ClassB to the
classBs Collection; we then lock the instance of ClassA for write, and
commit the transaction.

Extract :
ClassA a1 = new ClassA("A 1");
ClassB b1 = new ClassB("B 1");
a1.getClassBs().add(b1);

Transaction tx = null;
tx = odmg.newTransaction();
tx.begin();
tx.lock(a1, tx.WRITE);
tx.commit();

When the transaction is committed, the ClassA row is correctly inserted into
the database, and ClassB row is also inserted into the database.
Unfortunately, it is inserted twice, resulting in a Primary key violation
(I've remove the primary key constraint in the attatched SQL).

It is some time since I've been able to spend anytime on OJB, and so my
knowledge of its internals has faded somewhat. However, by stepping through
in debug, it seems that the the ClassB instance is committed twice, once in
the collection and once on it's own.

I attach the test case, the repository_user.xml and the SQL to create the
tables. We're using SQL Server, but I'm fairly sure this is a platform
independent problem.

Are we doing something wrong, or is this a bug ?

Thanks,

Charles.



This email and any attachments are strictly confidential and are intended
solely for the addressee. If you are not the intended recipient you must
not disclose, forward, copy or take any action in reliance on this message
or its attachments. If you have received this email in error please notify
the sender as soon as possible and delete it from your computer systems.
Any views or opinions presented are solely those of the author and do not
necessarily reflect those of HPD Software Limited or its affiliates.

 At present the integrity of email across the internet cannot be guaranteed
and messages sent via this medium are potentially at risk.  All liability
is excluded to the extent permitted by law for any claims arising as a re-
sult of the use of this medium to transmit information by or to 
HPD Software Limited or its affiliates.


          

[ojb-users] MySQL

[<Joa...@tp...>]

Hy,

In Case anyone wondered (or used an hour to search for the bug without
finding, like I did): When the OptimisticLockingTest of the JUnit Test-Suit
fails in MySQL, it might be, because the mm.mysql driver 2.0.11 (and
probably earlier versions as well) got a bug with Timestamps and daylight
saving time. Updateing to 2.0.12 helps.

regards
Joachim Sauer

[ojb-users] New release small problem

[Mark R. <Mar...@cr...>]

Hi

Just grabbed the new release and ran it successfully on SQL Server 2000. It
is probably worth mentioning that 
Microsoft JDBC driver is freely available on the Microsoft site...(don't
know whether it is allowable to redistribute it as
part of the OJB source (and the proposed binary) distribution. I am running
with latest JDK 1.4.0 release on Windows NT 4
sp6.

However, there is a small problem with build.xml. The preprocess task should
use classpathref in the java sub-task and not classpath e.g

Original build file has this

	<!-- Preprocess Java Source Code -->
	<target name="preprocess" depends="prepare">
        <echo message="using switches: ${JDK}, ${DEBUG}"/>
		<java fork="no" classname="org.hsqldb.util.CodeSwitcher"
failonerror="true" classpath="compilation-classpath">
			<arg value="${source}" />
            <arg value="${JDK}" />
            <arg value="${DEBUG}" />
		</java>
	</target>

Should be

	<!-- Preprocess Java Source Code -->
	<target name="preprocess" depends="prepare">
        <echo message="using switches: ${JDK}, ${DEBUG}"/>
		<java fork="no" classname="org.hsqldb.util.CodeSwitcher"
failonerror="true" classpathref="compilation-classpath">
			<arg value="${source}" />
            <arg value="${JDK}" />
            <arg value="${DEBUG}" />
		</java>
	</target>

On trying to run the unit tests on Access I came up against some problems.
All of them were to do with using the prepared statement setObject method
when the Java type was java.lang.Double and the SQL type was FLOAT. 
I modified PlatformMsAccessImpl to fix this problem. It is attached. However
there are 2 more problems in the unit tests
both due to NullPointerExceptions running the TypedCollectionTest. Here are
the summaries from the build results:

    [junit] 1)
testArray(test.ojb.broker.TypedCollectionsTest)junit.framework.AssertionFail
edError
    [junit] 	at
test.ojb.broker.TypedCollectionsTest.testArray(TypedCollectionsTest.java:114
)
    [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
    [junit] 	at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
    [junit] 	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
    [junit] 2)
testTypedCollection(test.ojb.broker.TypedCollectionsTest)junit.framework.Ass
ertionFailedError
    [junit] 	at
test.ojb.broker.TypedCollectionsTest.testTypedCollection(TypedCollectionsTes
t.java:139)
    [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
    [junit] 	at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
    [junit] 	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)

The stack trace in both cases is:

    [junit] java.lang.NullPointerException
    [junit] 	at
ojb.broker.accesslayer.IndirectionHandler.invoke(IndirectionHandler.java:160
)
    [junit] 	at $Proxy0.toString(Unknown Source)
    [junit] 	at java.lang.String.valueOf(String.java:2173)
    [junit] 	at java.lang.StringBuffer.append(StringBuffer.java:369)
    [junit] 	at
test.ojb.broker.ProductGroupWithArray.toString(ProductGroupWithArray.java:27
)
    [junit] 	at java.lang.String.valueOf(String.java:2173)
    [junit] 	at java.lang.StringBuffer.append(StringBuffer.java:369)
    [junit] 	at
ojb.broker.singlevm.PersistenceBrokerImpl.delete(PersistenceBrokerImpl.java:
134)
    [junit] 	at
test.ojb.broker.TypedCollectionsTest.testArray(TypedCollectionsTest.java:108
)
    [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
    [junit] 	at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
    [junit] 	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
    [junit] 	at java.lang.reflect.Method.invoke(Method.java:324)
    [junit] 	at junit.framework.TestCase.runTest(TestCase.java:166)
    [junit] 	at junit.framework.TestCase.runBare(TestCase.java:140)
    [junit] 	at junit.framework.TestResult$1.protect(TestResult.java:106)
    [junit] 	at
junit.framework.TestResult.runProtected(TestResult.java:124)
    [junit] 	at junit.framework.TestResult.run(TestResult.java:109)
    [junit] 	at junit.framework.TestCase.run(TestCase.java:131)
    [junit] 	at junit.framework.TestSuite.runTest(TestSuite.java:173)
    [junit] 	at junit.framework.TestSuite.run(TestSuite.java:168)
    [junit] 	at junit.framework.TestSuite.runTest(TestSuite.java:173)
    [junit] 	at junit.framework.TestSuite.run(TestSuite.java:168)
    [junit] 	at junit.textui.TestRunner.doRun(TestRunner.java:74)
    [junit] 	at junit.textui.TestRunner.start(TestRunner.java:234)
    [junit] 	at junit.textui.TestRunner.main(TestRunner.java:112)

OJB reports the following warning just before the error occurs in both
cases:

	WARN: OJB broker could not materialize
test.ojb.broker.InterfaceArticle{88881}

I will attempt to track this down and fix it.

Anyway, Thomas and everyone else involved in the development of OJB --
thanks very much for an excellent tool. It has
boosted my productivity no end...

Cheers

Mark

----------------------------------------------------------------
Mark Rowell
CreditTrade

T: +44 (0)207 7400 5078
M: mailto:mar...@cr...





CreditTrade Limited is regulated by the FSA.  © CreditTrade 2002.  All rights reserved.  The information and data contained in this email is provided for the information purposes of the addressee only and should not be reproduced and/or distributed to any other person.  It is provided without any warranty whatsoever and unless stated otherwise consists purely of indicative market prices and other information.

Any opinion or comments expressed or assumption made in association with the data or information provided in this email is a reflection of CreditTrade’s judgement at the time of compiling the data and is subject to change.  CreditTrade hereby makes no representation and accepts no responsibility or liability as to the completeness or accuracy of this email.

The content of this email is not intended as an offer or solicitation for, or recommendation of, the purchase or sale of any financial instrument, or as an official confirmation of any transaction, and should not be construed as investment advice.