FW: Materialising the wrong type of object when prefetching relat ionships where related class is part of extent
Sorry -- should have gone to ojb-user! BTW -- the class that OJB thinks it should get the class descriptor for is the "first" (look in ChainingIterator for what this means) concrete sub-class in the extent. Many thanks Mark -Original Message----- From: Mark Rowell Sent: 25 January 2005 12:25 To: 'ojb-dev@db.apache.org' Subject: Materialising the wrong type of object when prefetching relationships where related class is part of extent Hi I have loked on the ail list and found something similar to this. Certain times when I query a particular class That is not part of an extent but has (indirect) references to other objects that are part of an extent I get materialisation errors: org.apache.ojb.broker.metadata.MetadataException: IllegalAccess error setting field:rank in object:com.credittrade.instruments.derivatives.CreditDefaultSwap at org.apache.ojb.broker.accesslayer.BasePrefetcher.prefetchRelationship(BasePr efetcher.java:137) at org.apache.ojb.broker.core.QueryReferenceBroker.performRetrievalTasks(QueryR eferenceBroker.java:329) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryRe ferenceBroker.java:167) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryRe ferenceBroker.java:233) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryRe ferenceBroker.java:253) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Persis tenceBrokerImpl.java:1217) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery( DelegatingPersistenceBroker.java:338) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery( DelegatingPersistenceBroker.java:338) at com.credittrade.market.pc.options.OptionPriceLoader.fillOutReferenceLevels(O ptionPriceLoader.java:83) at com.credittrade.market.pc.PriceLoaderAbstractImpl.fillOutLastTraded(PriceLoa derAbstractImpl.java:313) at com.credittrade.market.pc.PriceLoaderAbstractImpl.initialLoad(PriceLoaderAbs tractImpl.java:57) at com.credittrade.market.pc.ClientPriceLoader$InitialLoad.execute(ClientPriceL oader.java:99) at com.credittrade.system.js.RPCTaskEntry.execute(RPCTaskEntry.java:63) at com.credittrade.system.js.TaskEntryProcessor.processEntry(TaskEntryProcessor .java:41) at com.credittrade.system.js.SpaceWorker$HandOff.run(SpaceWorker.java:230) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.ja va:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:6 75) at java.lang.Thread.run(Thread.java:595) After delving through the code even though OJB "knows" that I am trying to materialize an instance of a CreditDefaultSwap It is using the class/field descriptors for another type in the extent. The class I want (CreditDefaultSwap) Has a field converter for the field/column causing the problem but the other class does not & hence when OJB attempts to set The field into the object we get an IllegalAccessException as it is triyng to place an unconverted value into the field. All classes in the extent causing the problem are mapped onto a single table. The primary key is an INTEGER and is guarantted to be Unique (I have a UNIQUE PK constraint on the column) and I have queried the table for the relevant ID (for the problem object The primary key has the right ojbConcreteClass value in the table (CreditDefaultSwap). Has anyone come up against this before. I am using v1.0.1 & Java 5. The line numbers may not quite be correct as I have some print statement in place for debugging... Thanks Mark Rowell ------- Mark Rowell Structured Credit Europe CreditTrade Limited No. 1 London Bridge, 6th Floor London SE1 9QL Tel +44 (0)20 7098 1653 http://www.credittrade.com CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2005. 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 CreditTrades 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
Allocation of auto incremented primary keys between 2 JVMs
Hi Further to my mails last week re auto incremented primary keys (integers) across extents I have created a very simple (non Junit based) test that starts 2 JVMs that write A number of instances of a concrete class into a table using the PerssitenceBroker API. As it is currently setup, 2 JVMs are started that each attempt to insert 1000 instances. Everytime I have run it (10+) I get less than 2000 rows in the database or I will get a parimary key violation As one JVM attempts to store and ID that has already been created by the other JVM. I was under the impression that the default highLow sequence implementation would work across JVMs for allocating IDs? The attached zip file has everything in it. If one of the OJB developers could take a look at it I would appreciate it. Here is the stack trace: com.jnetdirect.jsql.v: Violation of PRIMARY KEY constraint 'PK__Test__72F0F4D3'. Cannot insert duplicate key in object 'Test'. at com.jnetdirect.jsql.v.a(Unknown Source) at com.jnetdirect.jsql.at.a(Unknown Source) at com.jnetdirect.jsql.af.i(Unknown Source) at com.jnetdirect.jsql.af.new(Unknown Source) at com.jnetdirect.jsql.af.int(Unknown Source) at com.jnetdirect.jsql.ao.executeUpdate(Unknown Source) at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeInsert(Unknow n Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(Unknown So urce) at org.apache.ojb.broker.core.PersistenceBrokerImpl.store(Unknown Source ) at org.apache.ojb.broker.core.PersistenceBrokerImpl.store(Unknown Source ) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(Unknown Source) at Test.main(Test.java:44) rethrown as org.apache.ojb.broker.PersistenceBrokerSQLException: Violation of PR IMARY KEY constraint 'PK__Test__72F0F4D3'. Cannot insert duplicate key in object 'Test'. at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeInsert(Unknow n Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(Unknown So urce) at org.apache.ojb.broker.core.PersistenceBrokerImpl.store(Unknown Source ) at org.apache.ojb.broker.core.PersistenceBrokerImpl.store(Unknown Source ) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(Unknown Source) at Test.main(Test.java:44) Caused by: com.jnetdirect.jsql.v: Violation of PRIMARY KEY constraint 'PK__Test_ _72F0F4D3'. Cannot insert duplicate key in object 'Test'. at com.jnetdirect.jsql.v.a(Unknown Source) at com.jnetdirect.jsql.at.a(Unknown Source) at com.jnetdirect.jsql.af.i(Unknown Source) at com.jnetdirect.jsql.af.new(Unknown Source) at com.jnetdirect.jsql.af.int(Unknown Source) at com.jnetdirect.jsql.ao.executeUpdate(Unknown Source) ... 7 more I am using RC4. This test has no caching. The RDBMS is SQLServer2000. To run the test extract the zip file to some directory. Go into that directory and create a lib sub-dir. Copy the RC4 jar all the commons jars (and the Jar that contains the logging code -- in my case log4j) You will need a batch file called JDK14.BAT somewhere on you path that sets the path to point to the JDK. The batch file run.bat starts 2 JVMs that write the info into the database. Regards Mark Rowell --- Mark Rowell Structured Credit Europe CreditTrade Limited 180 Fleet Street London EC4A 2HG Tel +44 (0)20 7400 5078 Fax +44 (0)20 7400 5099 http://www.credittrade.com CreditTrade Limited is regulated by the FSA. (c) 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 CreditTrades 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Auto incremented primary key and extents
Thanks Armin Are there any unit tests that explicitly cover this (e.g. storing objects of same type in 2 threads)? I am trying to test this running two JVMs that both store new instances of the same type of object and I (think that I) see non uniqueness of IDs occasionally. E.g the test basically involves me Inserting 2 sets of objects into the database in a single JVM & I get N rows stored in the database. When I clear down the table involved and run 2 JVMs to store one set of objects each I get a different total Number fo rows in the database. Perhaps I should come up with a small test setup which someone could run Independently to make sure I am not screwing up. Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 29 October 2003 15:40 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi again, Mark Rowell wrote: > Hi Armin > > Just one more question, so looking at the FAQ, I should basically add > a version (say private int ojbVersion) field to every class I want to > store instanes of in the database and change the repository > accordingly? > only to get unique id's across different JVMs? no (it's all managed by OJB). yes, if you want to use optimistic locking for all your objects (to avoid dealing with stale data and overwrite changes made by another thread/JVM). Maybe this will help you http://www.mail-archive.com/[EMAIL PROTECTED]/msg03792.html regards, Armin > Thanks > > Mark > > -Original Message- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > Sent: 29 October 2003 14:40 > To: OJB Users List > Subject: Re: Auto incremented primary key and extents > > > Hi Mark, > > Mark Rowell wrote: > > >>To anyone on the list >> >>Can you tell me how the SequenvceManagerHighLowImpl guarantees >>uniqueness of autoincremented Id's across JVMs -- I cant work out how >>it does it from the code >> > > (across JVMs using OJB) > it use optimistic locking. (http://db.apache.org/ojb/faq.html#How to > set up Optimistic Locking) > > See > SequenceManagerHighLowImpl#getSequence(...) > method. > If a new set of keys (e.g. next 20, from 221-240) was requested a > HighLowSequence object was read from DB. This instance has a version > number. If know another sequence manager instance (another thread or > instance in different JVM) update the same HighLowSequence (same row > in DB) the version number change. If we now try to store the requested > HighLowSequence we will get an OptimisticLockingException. > > regards, > Armin > > >>Thanks >> >>Mark Rowell >> >>-Original Message- >>From: Mark Rowell [mailto:[EMAIL PROTECTED] >>Sent: 29 October 2003 13:38 >>To: 'OJB Users List' >>Subject: RE: Auto incremented primary key and extents >> >> >>Sorry -- I guess I am already using SequenceManagerHighLowImpl...(I >>should know this!).. So as it stands using RC4 I should be OK with >>multiple JVMs accessing the database using the HighLowImpl sequence >>manager. >> >>Thanks >> >>Mark >> >>-Original Message- >>From: Armin Waibel [mailto:[EMAIL PROTECTED] >>Sent: 29 October 2003 13:28 >>To: OJB Users List >>Subject: Re: Auto incremented primary key and extents >> >> >>Hi Mark, >> >>Mark Rowell wrote: >> >> >>>Armin >>> >>>Sorry for being thick -- I looked at the code again and understood >>>and >>>tested it! As an aside, is there a sequence generator that will be >>>unique across multiple JVMs (and therefore OJB instances) accessing >>>the database at the same time? >>> >> >>yep! >> >>- SequenceManagerNextValImpl (use database based sequences, calling >>'nextval' command). Unique across different JVM and different apps >>using sequences too. >> >>- since SequenceManagerHighLowImpl use optimistic locking >>(>= rc3) this sequence manager implementation should be unique across >>JVM. >> >>regards, >>Armin >> >> >> >>>Thanks >>> >>>Mark >>> >>>-Original Message- >>>From: Armin Waibel [mailto:[EMAIL PROTECTED] >>>Sent: 28 October 2003 20:08 >>>To: OJB Users List >>>Subject: Re: Auto incremented primary key and extents >>> >>> >>>Hi Mark, >>> >>>Mark Rowell wrote: >>> >>> >>> >>> >>>>Armin >>>> >>>>On this note, with batch mode set to false, I decided to look into
RE: Auto incremented primary key and extents
Hi Armin Just one more question, so looking at the FAQ, I should basically add a version (say private int ojbVersion) field to every class I want to store instanes of in the database and change the repository accordingly? Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 29 October 2003 14:40 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: > To anyone on the list > > Can you tell me how the SequenvceManagerHighLowImpl guarantees > uniqueness of autoincremented Id's across JVMs -- I cant work out how > it does it from the code > (across JVMs using OJB) it use optimistic locking. (http://db.apache.org/ojb/faq.html#How to set up Optimistic Locking) See SequenceManagerHighLowImpl#getSequence(...) method. If a new set of keys (e.g. next 20, from 221-240) was requested a HighLowSequence object was read from DB. This instance has a version number. If know another sequence manager instance (another thread or instance in different JVM) update the same HighLowSequence (same row in DB) the version number change. If we now try to store the requested HighLowSequence we will get an OptimisticLockingException. regards, Armin > Thanks > > Mark Rowell > > -----Original Message- > From: Mark Rowell [mailto:[EMAIL PROTECTED] > Sent: 29 October 2003 13:38 > To: 'OJB Users List' > Subject: RE: Auto incremented primary key and extents > > > Sorry -- I guess I am already using SequenceManagerHighLowImpl...(I > should know this!).. So as it stands using RC4 I should be OK with > multiple JVMs accessing the database using the HighLowImpl sequence > manager. > > Thanks > > Mark > > -Original Message- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > Sent: 29 October 2003 13:28 > To: OJB Users List > Subject: Re: Auto incremented primary key and extents > > > Hi Mark, > > Mark Rowell wrote: > >>Armin >> >>Sorry for being thick -- I looked at the code again and understood and >>tested it! As an aside, is there a sequence generator that will be >>unique across multiple JVMs (and therefore OJB instances) accessing >>the database at the same time? >> > > yep! > > - SequenceManagerNextValImpl (use database based sequences, calling > 'nextval' command). Unique across different JVM and different apps > using sequences too. > > - since SequenceManagerHighLowImpl use optimistic locking > (>= rc3) this sequence manager implementation should be unique across > JVM. > > regards, > Armin > > >>Thanks >> >>Mark >> >>-Original Message- >>From: Armin Waibel [mailto:[EMAIL PROTECTED] >>Sent: 28 October 2003 20:08 >>To: OJB Users List >>Subject: Re: Auto incremented primary key and extents >> >> >>Hi Mark, >> >>Mark Rowell wrote: >> >> >> >>>Armin >>> >>>On this note, with batch mode set to false, I decided to look into >>>sequences in OJB. I currently use the default hi low sequence. I have >>>an extent where the top level class is an interface And some concrete >>>classes about 2 further levels down e.g. >>> >>> TopLevelInterface >>>+ >>> +-++ >>> Interface1 Interface2 Interface3 >>> + + >>>+++---+ >>> Impl1 Impl2 Impl3 Impl4 etc >>> >>>I often query things from the top level or one of the intermediate >>>levels (Interface1 to 3 above). My question regarding sequences is >>>that I have cleared out OJB_HL_SEQ as reocmmended in the documentation >>>When changing repository/extents) and I notice that although the max >>>ID >> >>for >> >> >>>the extent with TopLevelInterface >>>At the top is correct the sequence name appears to be Interface1. The >> >>first >> >> >>>thing I did was save some instances of Impl1 and Impl2. Surely for >>>this to work next time the VM starts I would have to have the >>>sequence name of ToplevelInterface so that the IDs are unique across >>>the entire extent >> >>(e.g. >> >>>from ToplevelInterface down) >> >>>The reason I say this is that if I start storing instances of Impl3 >>>and 4 say, how will they get the right Sequence e.gf. Interface1 is >>>not "visible" from Impl3 or 4 -- th
RE: Auto incremented primary key and extents
To anyone on the list Can you tell me how the SequenvceManagerHighLowImpl guarantees uniqueness of autoincremented Id's across JVMs -- I cant work out how it does it from the code Thanks Mark Rowell -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 29 October 2003 13:38 To: 'OJB Users List' Subject: RE: Auto incremented primary key and extents Sorry -- I guess I am already using SequenceManagerHighLowImpl...(I should know this!).. So as it stands using RC4 I should be OK with multiple JVMs accessing the database using the HighLowImpl sequence manager. Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 29 October 2003 13:28 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: > Armin > > Sorry for being thick -- I looked at the code again and understood and > tested it! As an aside, is there a sequence generator that will be > unique across multiple JVMs > (and therefore OJB instances) accessing the database at the same time? > yep! - SequenceManagerNextValImpl (use database based sequences, calling 'nextval' command). Unique across different JVM and different apps using sequences too. - since SequenceManagerHighLowImpl use optimistic locking (>= rc3) this sequence manager implementation should be unique across JVM. regards, Armin > Thanks > > Mark > > -Original Message- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > Sent: 28 October 2003 20:08 > To: OJB Users List > Subject: Re: Auto incremented primary key and extents > > > Hi Mark, > > Mark Rowell wrote: > > >>Armin >> >>On this note, with batch mode set to false, I decided to look into >>sequences in OJB. I currently use the default hi low sequence. I have >>an extent where the top level class is an interface And some concrete >>classes about 2 further levels down e.g. >> >> TopLevelInterface >> + >> +-++ >>Interface1 Interface2 Interface3 >> + + >> +++---+ >> Impl1 Impl2 Impl3 Impl4 etc >> >>I often query things from the top level or one of the intermediate >>levels (Interface1 to 3 above). My question regarding sequences is >>that I have cleared out OJB_HL_SEQ as reocmmended in the documentation >>When changing repository/extents) and I notice that although the max >>ID > > for > >>the extent with TopLevelInterface >>At the top is correct the sequence name appears to be Interface1. The > > first > >>thing I did was save some instances of Impl1 and Impl2. Surely for >>this to work next time the VM starts I would have to have the sequence >>name of ToplevelInterface so that the IDs are unique across the entire >>extent > > (e.g. > >>from ToplevelInterface down) >> >>The reason I say this is that if I start storing instances of Impl3 >>and 4 say, how will they get the right Sequence e.gf. Interface1 is >>not "visible" from Impl3 or 4 -- the only commonly visible interface >>is The top level one hence I would have expected the sequence to have >>this name. >> >>I hope you can (or someone can) shed some light on my confusion. >> > > doh! ;-) > first, I don't know how your class-descriptors are defined. > I will describe the best case scenario: > Need sequence name for Impl3 autoincrement field > Get TopLevel class for Impl3 --> TopLevelInterface > Is TopLevelInterface is extent? --> then try to find > first none null table name. Assume TopLevelInterface > has extents Interface1, Interface2, Interface3 > then OJB check all extents of Interface1,... for real > class and its table name (search recursive the first > none null table name - that's the reason for the note > in the docs). The result for sequence > name maybe SEQ_IMPL1_TABLE. Thus all real classes > should get the same unique sequence name SEQ_IMPL1_TABLE. > > Why not use name of the top level class as sequence name? Assume you > map the classes Fish and Mammal (no collective interface or base > class) to one table. Then top level class name is equivalent to class > names and you will end up with two different sequence names for the > same table --> duplicate sequence keys. > > I will be happy if you find a better solution :-) > > By the way, if you don't trust the auto-generated sequence name for > such complex mappings, declare a sequence name in the field-des
RE: Auto incremented primary key and extents
Sorry -- I guess I am already using SequenceManagerHighLowImpl...(I should know this!).. So as it stands using RC4 I should be OK with multiple JVMs accessing the database using the HighLowImpl sequence manager. Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 29 October 2003 13:28 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: > Armin > > Sorry for being thick -- I looked at the code again and understood and > tested it! As an aside, is there a sequence generator that will be > unique across multiple JVMs > (and therefore OJB instances) accessing the database at the same time? > yep! - SequenceManagerNextValImpl (use database based sequences, calling 'nextval' command). Unique across different JVM and different apps using sequences too. - since SequenceManagerHighLowImpl use optimistic locking (>= rc3) this sequence manager implementation should be unique across JVM. regards, Armin > Thanks > > Mark > > -Original Message- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > Sent: 28 October 2003 20:08 > To: OJB Users List > Subject: Re: Auto incremented primary key and extents > > > Hi Mark, > > Mark Rowell wrote: > > >>Armin >> >>On this note, with batch mode set to false, I decided to look into >>sequences in OJB. I currently use the default hi low sequence. I have >>an extent where the top level class is an interface >>And some concrete classes about 2 further levels down e.g. >> >> TopLevelInterface >> + >> +-++ >>Interface1 Interface2 Interface3 >> + + >> +++---+ >> Impl1 Impl2 Impl3 Impl4 etc >> >>I often query things from the top level or one of the intermediate >>levels (Interface1 to 3 above). My question regarding sequences is >>that I have cleared out OJB_HL_SEQ as reocmmended in the documentation >>When changing repository/extents) and I notice that although the max ID > > for > >>the extent with TopLevelInterface >>At the top is correct the sequence name appears to be Interface1. The > > first > >>thing I did was save some instances of Impl1 and Impl2. Surely for >>this to work next time the VM starts I would have to have the sequence >>name of ToplevelInterface so that the IDs are unique across the entire >>extent > > (e.g. > >>from ToplevelInterface down) >> >>The reason I say this is that if I start storing instances of Impl3 >>and 4 say, how will they get the right Sequence e.gf. Interface1 is >>not "visible" from Impl3 or 4 -- the only commonly visible interface >>is The top level one hence I would have expected the sequence to have >>this name. >> >>I hope you can (or someone can) shed some light on my confusion. >> > > doh! ;-) > first, I don't know how your class-descriptors are defined. > I will describe the best case scenario: > Need sequence name for Impl3 autoincrement field > Get TopLevel class for Impl3 --> TopLevelInterface > Is TopLevelInterface is extent? --> then try to find > first none null table name. Assume TopLevelInterface > has extents Interface1, Interface2, Interface3 > then OJB check all extents of Interface1,... for real > class and its table name (search recursive the first > none null table name - that's the reason for the note > in the docs). The result for sequence > name maybe SEQ_IMPL1_TABLE. Thus all real classes > should get the same unique sequence name SEQ_IMPL1_TABLE. > > Why not use name of the top level class as sequence name? Assume you > map the classes Fish and Mammal (no collective interface or base > class) to one table. Then top level class name is equivalent to class > names and you will end up with two different sequence names for the > same table --> duplicate sequence keys. > > I will be happy if you find a better solution :-) > > By the way, if you don't trust the auto-generated sequence name for > such complex mappings, declare a sequence name in the field-descriptor > of your classes. > > regards, > Armin > > >>Regards, >> >>Mark Rowell >>-Original Message- >>From: Armin Waibel [mailto:[EMAIL PROTECTED] >>Sent: 27 October 2003 12:50 >>To: OJB Users List >>Subject: Re: Auto incremented primary key and extents >> >> >>Hi Mark, >> >>Mark Rowell wrote: >&g
RE: Auto incremented primary key and extents
Armin Thanks -- to switch from Hi low to SequenceManagerNextValImpl/SequenceManagerHighLowImpl is there anything I should do to the OJB system tables etc apart from change OJB configuration accordingly? (apart from me doing the RTFM thing...) Cheers Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 29 October 2003 13:28 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: > Armin > > Sorry for being thick -- I looked at the code again and understood and > tested it! As an aside, is there a sequence generator that will be > unique across multiple JVMs > (and therefore OJB instances) accessing the database at the same time? > yep! - SequenceManagerNextValImpl (use database based sequences, calling 'nextval' command). Unique across different JVM and different apps using sequences too. - since SequenceManagerHighLowImpl use optimistic locking (>= rc3) this sequence manager implementation should be unique across JVM. regards, Armin > Thanks > > Mark > > -Original Message- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > Sent: 28 October 2003 20:08 > To: OJB Users List > Subject: Re: Auto incremented primary key and extents > > > Hi Mark, > > Mark Rowell wrote: > > >>Armin >> >>On this note, with batch mode set to false, I decided to look into >>sequences in OJB. I currently use the default hi low sequence. I have >>an extent where the top level class is an interface >>And some concrete classes about 2 further levels down e.g. >> >> TopLevelInterface >> + >> +-++ >>Interface1 Interface2 Interface3 >> + + >> +++---+ >> Impl1 Impl2 Impl3 Impl4 etc >> >>I often query things from the top level or one of the intermediate >>levels (Interface1 to 3 above). My question regarding sequences is >>that I have cleared out OJB_HL_SEQ as reocmmended in the documentation >>When changing repository/extents) and I notice that although the max ID > > for > >>the extent with TopLevelInterface >>At the top is correct the sequence name appears to be Interface1. The > > first > >>thing I did was save some instances of Impl1 and Impl2. Surely for >>this to work next time the VM starts I would have to have the sequence >>name of ToplevelInterface so that the IDs are unique across the entire >>extent > > (e.g. > >>from ToplevelInterface down) >> >>The reason I say this is that if I start storing instances of Impl3 >>and 4 say, how will they get the right Sequence e.gf. Interface1 is >>not "visible" from Impl3 or 4 -- the only commonly visible interface >>is The top level one hence I would have expected the sequence to have >>this name. >> >>I hope you can (or someone can) shed some light on my confusion. >> > > doh! ;-) > first, I don't know how your class-descriptors are defined. > I will describe the best case scenario: > Need sequence name for Impl3 autoincrement field > Get TopLevel class for Impl3 --> TopLevelInterface > Is TopLevelInterface is extent? --> then try to find > first none null table name. Assume TopLevelInterface > has extents Interface1, Interface2, Interface3 > then OJB check all extents of Interface1,... for real > class and its table name (search recursive the first > none null table name - that's the reason for the note > in the docs). The result for sequence > name maybe SEQ_IMPL1_TABLE. Thus all real classes > should get the same unique sequence name SEQ_IMPL1_TABLE. > > Why not use name of the top level class as sequence name? Assume you > map the classes Fish and Mammal (no collective interface or base > class) to one table. Then top level class name is equivalent to class > names and you will end up with two different sequence names for the > same table --> duplicate sequence keys. > > I will be happy if you find a better solution :-) > > By the way, if you don't trust the auto-generated sequence name for > such complex mappings, declare a sequence name in the field-descriptor > of your classes. > > regards, > Armin > > >>Regards, >> >>Mark Rowell >>-Original Message- >>From: Armin Waibel [mailto:[EMAIL PROTECTED] >>Sent: 27 October 2003 12:50 >>To: OJB Users List >>Subject: Re: Auto incremented primary key and extents >> >> >>Hi Mark, >>
RE: Auto incremented primary key and extents
Armin Sorry for being thick -- I looked at the code again and understood and tested it! As an aside, is there a sequence generator that will be unique across multiple JVMs (and therefore OJB instances) accessing the database at the same time? Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 28 October 2003 20:08 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: > Armin > > On this note, with batch mode set to false, I decided to look into > sequences in OJB. I currently use the default hi low sequence. I have > an extent where the top level class is an interface > And some concrete classes about 2 further levels down e.g. > > TopLevelInterface > + >+-++ > Interface1 Interface2 Interface3 >+ + > +++---+ >Impl1 Impl2 Impl3 Impl4 etc > > I often query things from the top level or one of the intermediate > levels (Interface1 to 3 above). My question regarding sequences is > that I have cleared out OJB_HL_SEQ as reocmmended in the documentation > When changing repository/extents) and I notice that although the max ID for > the extent with TopLevelInterface > At the top is correct the sequence name appears to be Interface1. The first > thing I did was save some instances of Impl1 and Impl2. Surely for this to > work next time the VM starts I would have to have the sequence name of > ToplevelInterface so that the IDs are unique across the entire extent (e.g. > from ToplevelInterface down) > > The reason I say this is that if I start storing instances of Impl3 > and 4 say, how will they get the right Sequence e.gf. Interface1 is > not "visible" from Impl3 or 4 -- the only commonly visible interface > is The top level one hence I would have expected the sequence to have > this name. > > I hope you can (or someone can) shed some light on my confusion. > doh! ;-) first, I don't know how your class-descriptors are defined. I will describe the best case scenario: Need sequence name for Impl3 autoincrement field Get TopLevel class for Impl3 --> TopLevelInterface Is TopLevelInterface is extent? --> then try to find first none null table name. Assume TopLevelInterface has extents Interface1, Interface2, Interface3 then OJB check all extents of Interface1,... for real class and its table name (search recursive the first none null table name - that's the reason for the note in the docs). The result for sequence name maybe SEQ_IMPL1_TABLE. Thus all real classes should get the same unique sequence name SEQ_IMPL1_TABLE. Why not use name of the top level class as sequence name? Assume you map the classes Fish and Mammal (no collective interface or base class) to one table. Then top level class name is equivalent to class names and you will end up with two different sequence names for the same table --> duplicate sequence keys. I will be happy if you find a better solution :-) By the way, if you don't trust the auto-generated sequence name for such complex mappings, declare a sequence name in the field-descriptor of your classes. regards, Armin > Regards, > > Mark Rowell > -Original Message- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > Sent: 27 October 2003 12:50 > To: OJB Users List > Subject: Re: Auto incremented primary key and extents > > > Hi Mark, > > Mark Rowell wrote: > >>Sorry >> >>After looking at SequenceManaherHelper I know that the max id of >>sequence for extent is not... >> >>More on the batch mode stuff -- I onlt just turned it on and got these >>problems. RC4 has been working Prior to setting batch-mode="true" in >>the configuration. >> > > hmm, AFAIK Oleg has fixed some bugs in conjunction > with batch mode (since rc4). So your problems maybe > a side-effect of the bugs in batch-mode. > > regards, > Armin > > >>-Original Message- >>From: Mark Rowell [mailto:[EMAIL PROTECTED] >>Sent: 27 October 2003 12:25 >>To: 'OJB Users List' >>Subject: RE: Auto incremented primary key and extents >> >> >>Armin >> >>No the only thing I changed was OJB.properties. >> >>One thing is that this problem happened during a run of my application >>where some batch mode=true stuff Was used. Would this have an impact? >> >>Is the sequence max id still stored in OJB_HL_SEQ? >> >>Regards >> >>Mark >> >>-Original Message- >>From: Armin Waibel [mailto:[EMAIL
RE: Auto incremented primary key and extents
Armin On this note, with batch mode set to false, I decided to look into sequences in OJB. I currently use the default hi low sequence. I have an extent where the top level class is an interface And some concrete classes about 2 further levels down e.g. TopLevelInterface + +-++ Interface1 Interface2 Interface3 + + +++---+ Impl1 Impl2 Impl3 Impl4 etc I often query things from the top level or one of the intermediate levels (Interface1 to 3 above). My question regarding sequences is that I have cleared out OJB_HL_SEQ as reocmmended in the documentation When changing repository/extents) and I notice that although the max ID for the extent with TopLevelInterface At the top is correct the sequence name appears to be Interface1. The first thing I did was save some instances of Impl1 and Impl2. Surely for this to work next time the VM starts I would have to have the sequence name of ToplevelInterface so that the IDs are unique across the entire extent (e.g. from ToplevelInterface down) The reason I say this is that if I start storing instances of Impl3 and 4 say, how will they get the right Sequence e.gf. Interface1 is not "visible" from Impl3 or 4 -- the only commonly visible interface is The top level one hence I would have expected the sequence to have this name. I hope you can (or someone can) shed some light on my confusion. Regards, Mark Rowell -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:50 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: > Sorry > > After looking at SequenceManaherHelper I know that the max id of > sequence for extent is not... > > More on the batch mode stuff -- I onlt just turned it on and got these > problems. RC4 has been working Prior to setting batch-mode="true" in > the configuration. > hmm, AFAIK Oleg has fixed some bugs in conjunction with batch mode (since rc4). So your problems maybe a side-effect of the bugs in batch-mode. regards, Armin > -Original Message- > From: Mark Rowell [mailto:[EMAIL PROTECTED] > Sent: 27 October 2003 12:25 > To: 'OJB Users List' > Subject: RE: Auto incremented primary key and extents > > > Armin > > No the only thing I changed was OJB.properties. > > One thing is that this problem happened during a run of my application > where some batch mode=true stuff Was used. Would this have an impact? > > Is the sequence max id still stored in OJB_HL_SEQ? > > Regards > > Mark > > -Original Message- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > Sent: 27 October 2003 12:21 > To: OJB Users List > Subject: Re: Auto incremented primary key and extents > > > Hi Mark, > > > But as a follow on the extents are more than one level deep -- > would > this > have an impact? No should not. Have a look in > SequenceManagerHelper#getMaxForExtent > > > > unique Over all tables in the extent? Have I misconfigured OJB on > upgrading > > to RC4? > Did you change metadata on upgrading? Add new extents, > change order of declaration? > > regards, > Armin > > > Mark Rowell wrote: > > >>Sorry >> >>But as a follow on the extents are more than one level deep -- would >>this have an impact? >> >>Regards, >> >>Mark Rowell >> >>-Original Message- >>From: Mark Rowell [mailto:[EMAIL PROTECTED] >>Sent: 27 October 2003 11:30 >>To: '[EMAIL PROTECTED]' >>Subject: Auto incremented primary key and extents >> >> >>Hi >> >>I have an extent over 8 classes (and 8 corresponding tables) and I >>have noticed that primary keys are now not unique over all tables -- >>e.g. when I store and instances of 2 different classes In different >>"leaves" of the extent I get the same ID in both tables. In RC1 I the >>autogenerated IDs were unique Over all tables in the extent? Have I >>misconfigured OJB on upgrading to RC4? >> >>Regards, >> >>Mark Rowell >> >>--- >>Mark Rowell >>Structured Credit Europe >>CreditTrade Limited >>180 Fleet Street >>London EC4A 2HG >> >>Tel +44 (0)20 7400 5078 >>Fax +44 (0)20 7400 5099 >> >>http://www.credittrade.com >> >> >> >>CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All >>rights reserved. The information and data contained in
RE: Auto incremented primary key and extents
Thanks Andy I have set batch mode to false just to be on the safe side...i have used batch mode on earlier versions of OJB and not had any problems as far as I could tell... ;-) Cheers, Mark -Original Message- From: Andy Czerwonka [mailto:[EMAIL PROTECTED] Sent: 28 October 2003 15:05 To: OJB Users List Subject: RE: Auto incremented primary key and extents autogenerated keys using the DefaultSequenceManagerImpl are not assigned on broker.store(obj) using batch-mode=true. I'm wondering if the hash gets messed up (ordering) on the batch. On Mon, 2003-10-27 at 05:25, Mark Rowell wrote: > Armin > > No the only thing I changed was OJB.properties. > > One thing is that this problem happened during a run of my application > where some batch mode=true stuff Was used. Would this have an impact? > > Is the sequence max id still stored in OJB_HL_SEQ? > > Regards > > Mark > > -Original Message- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > Sent: 27 October 2003 12:21 > To: OJB Users List > Subject: Re: Auto incremented primary key and extents > > > Hi Mark, > > > But as a follow on the extents are more than one level deep -- > would > this > have an impact? No should not. Have a look in > SequenceManagerHelper#getMaxForExtent > > > > unique Over all tables in the extent? Have I misconfigured OJB on > upgrading > > to RC4? > Did you change metadata on upgrading? Add new extents, > change order of declaration? > > regards, > Armin > > > Mark Rowell wrote: > > > Sorry > > > > But as a follow on the extents are more than one level deep -- would > > this have an impact? > > > > Regards, > > > > Mark Rowell > > > > -Original Message- > > From: Mark Rowell [mailto:[EMAIL PROTECTED] > > Sent: 27 October 2003 11:30 > > To: '[EMAIL PROTECTED]' > > Subject: Auto incremented primary key and extents > > > > > > Hi > > > > I have an extent over 8 classes (and 8 corresponding tables) and I > > have noticed that primary keys are now not unique over all tables -- > > e.g. when I store and instances of 2 different classes In different > > "leaves" of the extent I get the same ID in both tables. In RC1 I the > > autogenerated IDs were unique Over all tables in the extent? Have I > > misconfigured OJB on upgrading to RC4? > > > > Regards, > > > > Mark Rowell > > > > --- > > Mark Rowell > > Structured Credit Europe > > CreditTrade Limited > > 180 Fleet Street > > London EC4A 2HG > > > > Tel +44 (0)20 7400 5078 > > Fax +44 (0)20 7400 5099 > > > > http://www.credittrade.com > > > > > > > > CreditTrade Limited is regulated by the FSA. (c) 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 > > CreditTrades 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. > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > CreditTrade Limited is regulated by the FSA. (c) 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. > > > >
RE: Auto incremented primary key and extents
Armin Thanks -- don't suppose you could grab me a CVS head could you if you get the chance... Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:50 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: > Sorry > > After looking at SequenceManaherHelper I know that the max id of > sequence for extent is not... > > More on the batch mode stuff -- I onlt just turned it on and got these > problems. RC4 has been working Prior to setting batch-mode="true" in > the configuration. > hmm, AFAIK Oleg has fixed some bugs in conjunction with batch mode (since rc4). So your problems maybe a side-effect of the bugs in batch-mode. regards, Armin > -Original Message- > From: Mark Rowell [mailto:[EMAIL PROTECTED] > Sent: 27 October 2003 12:25 > To: 'OJB Users List' > Subject: RE: Auto incremented primary key and extents > > > Armin > > No the only thing I changed was OJB.properties. > > One thing is that this problem happened during a run of my application > where some batch mode=true stuff Was used. Would this have an impact? > > Is the sequence max id still stored in OJB_HL_SEQ? > > Regards > > Mark > > -Original Message- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > Sent: 27 October 2003 12:21 > To: OJB Users List > Subject: Re: Auto incremented primary key and extents > > > Hi Mark, > > > But as a follow on the extents are more than one level deep -- > would > this > have an impact? No should not. Have a look in > SequenceManagerHelper#getMaxForExtent > > > > unique Over all tables in the extent? Have I misconfigured OJB on > upgrading > > to RC4? > Did you change metadata on upgrading? Add new extents, > change order of declaration? > > regards, > Armin > > > Mark Rowell wrote: > > >>Sorry >> >>But as a follow on the extents are more than one level deep -- would >>this have an impact? >> >>Regards, >> >>Mark Rowell >> >>-Original Message- >>From: Mark Rowell [mailto:[EMAIL PROTECTED] >>Sent: 27 October 2003 11:30 >>To: '[EMAIL PROTECTED]' >>Subject: Auto incremented primary key and extents >> >> >>Hi >> >>I have an extent over 8 classes (and 8 corresponding tables) and I >>have noticed that primary keys are now not unique over all tables -- >>e.g. when I store and instances of 2 different classes In different >>"leaves" of the extent I get the same ID in both tables. In RC1 I the >>autogenerated IDs were unique Over all tables in the extent? Have I >>misconfigured OJB on upgrading to RC4? >> >>Regards, >> >>Mark Rowell >> >>--- >>Mark Rowell >>Structured Credit Europe >>CreditTrade Limited >>180 Fleet Street >>London EC4A 2HG >> >>Tel +44 (0)20 7400 5078 >>Fax +44 (0)20 7400 5099 >> >>http://www.credittrade.com >> >> >> >>CreditTrade Limited is regulated by the FSA. (c) 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 >>CreditTrades 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. >> >>- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >>CreditTrade Limited is regulated by the FSA. (c) 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 >&
RE: Auto incremented primary key and extents
Sorry After looking at SequenceManaherHelper I know that the max id of sequence for extent is not... More on the batch mode stuff -- I onlt just turned it on and got these problems. RC4 has been working Prior to setting batch-mode="true" in the configuration. -Original Message----- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:25 To: 'OJB Users List' Subject: RE: Auto incremented primary key and extents Armin No the only thing I changed was OJB.properties. One thing is that this problem happened during a run of my application where some batch mode=true stuff Was used. Would this have an impact? Is the sequence max id still stored in OJB_HL_SEQ? Regards Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:21 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, > But as a follow on the extents are more than one level deep -- would > this > have an impact? No should not. Have a look in SequenceManagerHelper#getMaxForExtent > unique Over all tables in the extent? Have I misconfigured OJB on upgrading > to RC4? Did you change metadata on upgrading? Add new extents, change order of declaration? regards, Armin Mark Rowell wrote: > Sorry > > But as a follow on the extents are more than one level deep -- would > this have an impact? > > Regards, > > Mark Rowell > > -Original Message- > From: Mark Rowell [mailto:[EMAIL PROTECTED] > Sent: 27 October 2003 11:30 > To: '[EMAIL PROTECTED]' > Subject: Auto incremented primary key and extents > > > Hi > > I have an extent over 8 classes (and 8 corresponding tables) and I > have noticed that primary keys are now not unique over all tables -- > e.g. when I store and instances of 2 different classes In different > "leaves" of the extent I get the same ID in both tables. In RC1 I the > autogenerated IDs were unique Over all tables in the extent? Have I > misconfigured OJB on upgrading to RC4? > > Regards, > > Mark Rowell > > --- > Mark Rowell > Structured Credit Europe > CreditTrade Limited > 180 Fleet Street > London EC4A 2HG > > Tel +44 (0)20 7400 5078 > Fax +44 (0)20 7400 5099 > > http://www.credittrade.com > > > > CreditTrade Limited is regulated by the FSA. (c) 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 > CreditTrades 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. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > CreditTrade Limited is regulated by the FSA. (c) 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 > CreditTrades 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. > > - > To unsubscribe,
RE: Auto incremented primary key and extents
Armin No the only thing I changed was OJB.properties. One thing is that this problem happened during a run of my application where some batch mode=true stuff Was used. Would this have an impact? Is the sequence max id still stored in OJB_HL_SEQ? Regards Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:21 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, > But as a follow on the extents are more than one level deep -- would > this > have an impact? No should not. Have a look in SequenceManagerHelper#getMaxForExtent > unique Over all tables in the extent? Have I misconfigured OJB on upgrading > to RC4? Did you change metadata on upgrading? Add new extents, change order of declaration? regards, Armin Mark Rowell wrote: > Sorry > > But as a follow on the extents are more than one level deep -- would > this have an impact? > > Regards, > > Mark Rowell > > -Original Message- > From: Mark Rowell [mailto:[EMAIL PROTECTED] > Sent: 27 October 2003 11:30 > To: '[EMAIL PROTECTED]' > Subject: Auto incremented primary key and extents > > > Hi > > I have an extent over 8 classes (and 8 corresponding tables) and I > have noticed that primary keys are now not unique over all tables -- > e.g. when I store and instances of 2 different classes In different > "leaves" of the extent I get the same ID in both tables. In RC1 I the > autogenerated IDs were unique Over all tables in the extent? Have I > misconfigured OJB on upgrading to RC4? > > Regards, > > Mark Rowell > > --- > Mark Rowell > Structured Credit Europe > CreditTrade Limited > 180 Fleet Street > London EC4A 2HG > > Tel +44 (0)20 7400 5078 > Fax +44 (0)20 7400 5099 > > http://www.credittrade.com > > > > CreditTrade Limited is regulated by the FSA. (c) 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 > CreditTrades 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. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > CreditTrade Limited is regulated by the FSA. (c) 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 > CreditTrades 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. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All rights reserved. The information and data contained in this email is provided for the information purposes of th
RE: Auto incremented primary key and extents
Sorry But as a follow on the extents are more than one level deep -- would this have an impact? Regards, Mark Rowell -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 11:30 To: '[EMAIL PROTECTED]' Subject: Auto incremented primary key and extents Hi I have an extent over 8 classes (and 8 corresponding tables) and I have noticed that primary keys are now not unique over all tables -- e.g. when I store and instances of 2 different classes In different "leaves" of the extent I get the same ID in both tables. In RC1 I the autogenerated IDs were unique Over all tables in the extent? Have I misconfigured OJB on upgrading to RC4? Regards, Mark Rowell --- Mark Rowell Structured Credit Europe CreditTrade Limited 180 Fleet Street London EC4A 2HG Tel +44 (0)20 7400 5078 Fax +44 (0)20 7400 5099 http://www.credittrade.com CreditTrade Limited is regulated by the FSA. (c) 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 CreditTrades 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) 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 CreditTrades 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Auto incremented primary key and extents
Hi I have an extent over 8 classes (and 8 corresponding tables) and I have noticed that primary keys are now not unique over all tables -- e.g. when I store and instances of 2 different classes In different "leaves" of the extent I get the same ID in both tables. In RC1 I the autogenerated IDs were unique Over all tables in the extent? Have I misconfigured OJB on upgrading to RC4? Regards, Mark Rowell --- Mark Rowell Structured Credit Europe CreditTrade Limited 180 Fleet Street London EC4A 2HG Tel +44 (0)20 7400 5078 Fax +44 (0)20 7400 5099 http://www.credittrade.com CreditTrade Limited is regulated by the FSA. (c) 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 CreditTrades 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: someone please tell me...
Andy I found this as well but I have taken the extra step of prechecking which of my objects exist so rather Than doing a broker.store(object) I can call the store method that tells OJB to update or insert -- stops OJB querying to see if object exists. Must admit it does seem strange though... Mark -Original Message- From: Andy Czerwonka [mailto:[EMAIL PROTECTED] Sent: 25 October 2003 00:53 To: OJB Users List Subject: someone please tell me... How could batch-mode=true be slower than batch-mode=false??? OJB rc4 + small batch-mode hack (Mark Rowell) Oracle9i ojdbc14.jar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) 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 CreditTrades 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: problems with batch-mode=true
Armin
No because I am not allowed to use CVS where I work..hence...
Oh well!
Thanks
Mark
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: 23 October 2003 11:37
To: OJB Users List
Subject: Re: problems with batch-mode=true
Hi Mark,
did you tried latest version from CVS?
I think your mentioned bug was fixed in
CVS.
See
http://cvs.apache.org/viewcvs.cgi/db-ojb/src/java/org/apache/ojb/broker/util
/batch/PreparedStatementInvocationHandler.java
regards,
Armin
Mark Rowell wrote:
> Hi
>
> As a follow on I checked the source for java.lang.reflect.Method and
> it has an implementation Of equals which could possibly indicate tat
> the equality operator (==) does not hold for methods.
>
> Mark
>
> -Original Message-
> From: Mark Rowell [mailto:[EMAIL PROTECTED]
> Sent: 23 October 2003 10:23
> To: 'OJB Users List'
> Subject: RE: problems with batch-mode=true
>
>
> Hi
>
> Regarding this issue it looks like (at least as far as RC4 is
> concerned) that in the doExecute method of
> PreparedStatementInvocationHandler.java the following line (223) gets
> invoked
>
> ((Method) _methods.get(i)).invoke(stmt, (Object[]) _params.get(i));
>
> In my case when using batched mode, and JSQLConnect on MSSqlServer I
> get a similar error to Bonnie (java.lang.IllegalArgumentException:
> object is not an instance of declaring class)
>
> The methods returned by _methods.get(i) is
>
> public void
> org.apache.ojb.broker.platforms.PlatformDefaultImpl.addBatch(java.sql.
> Prepar
> edStatement)
>
> And we are trying to executed it on the statement rather than passing
> the platform instance. I think the problem Is in the if statement in
> that it does an == rather than a .equals() call to determine whether
> we want to call the addBatch method. Now, I do not know whether within
> a single JVM that the following Returns true
>
> Method method1 = obj.getClass().getMethod("methodName", );
> Method method2 = obj.getClass().getMethod("methodName", );
> method1 == method2; // is this gurantee dto be true like it is for
> instances of Class e.g.
>
> Obj.getClass() == Obj.getClass() is guranteed to be true?
>
> Regards,
>
> Mark Rowell
>
>
> -Original Message-
> From: Bonnie MacKellar [mailto:[EMAIL PROTECTED]
> Sent: 22 October 2003 14:02
> To: OJB Users List
> Subject: RE: problems with batch-mode=true
>
>
> Hi,
> Here is the code that I tested. You can
> see that setBatchMode is called before I start
> the tx.
> try
> {
> broker.serviceConnectionManager().setBatchMode(true);
> broker.beginTransaction();
> for (int i = 0; i < 100; i++)
> {
> CustomerInterface customer = new Customer();
> customer.setCustomerNumber("100" + i);
> customer.setFirstName("Big");
> customer.setLastName("Customer");
> customer.setCustomerName("BadCorporation");
> customer.setDeleteTag(Boolean.FALSE);
> broker.store(customer);
> }
> // conMan.executeBatch();
> broker.commitTransaction();
> }
> catch(Exception e)
> {
> e.printStackTrace();
> logger.error(e.getMessage());
> broker.abortTransaction();
> }
> finally
> {
> broker.close();
> }
>
> This chunk of code, exectued with batch-mode="true"
> in repository_database.xml, results in the following
> two exceptions :
> java.lang.IllegalArgumentException: object is not an instance of declaring
> class
> at java.lang.reflect.Method.invoke(Native Method)
> at
>
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.doExecut
> e(Unknown Source)
> at
>
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.invoke(U
> nknown Source)
> at $Proxy0.doExecute(Unknown Source)
> at
> org.apache.ojb.broker.util.batch.BatchConnection.executeBatch(Unknown
> Source)
> at org.apache.ojb.broker.util.batch.BatchConnection.commit(Unknown
> Source)
> at
>
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.localCommit(Unknown
> Source)
> at
> org.apache.ojb.broker.core.PersistenceBrokerImpl.commitTransaction(Unknown
> Source)
> at
>
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransa
RE: problems with batch-mode=true
Hi
Sorry for the flurry of emails but changing == to .equals in the doExecute
method of
PreparedStatementInvocationHandler fixes this problem.
Change line 214 in RC4 from
if ( ((Method)_methods.get(i)) ==
ADD_BATCH )
{
/**
* we invoke on the platform
and pass the stmt as an arg.
*/
((Method)
_methods.get(i)).invoke(m_platform, new Object[] {stmt});
}
else
{
((Method)
_methods.get(i)).invoke(stmt, (Object[]) _params.get(i));
}
if ( ADD_BATCH.equals(
_methods.get(i)) )
{
/**
* we invoke on the platform
and pass the stmt as an arg.
*/
((Method)
_methods.get(i)).invoke(m_platform, new Object[] {stmt});
}
else
{
((Method)
_methods.get(i)).invoke(stmt, (Object[]) _params.get(i));
}
BTW the cast in the equality is unecessary.
Regards
Mark Rowell
-Original Message-
From: Mark Rowell [mailto:[EMAIL PROTECTED]
Sent: 23 October 2003 10:27
To: 'OJB Users List'
Subject: RE: problems with batch-mode=true
Hi
As a follow on I checked the source for java.lang.reflect.Method and it has
an implementation Of equals which could possibly indicate tat the equality
operator (==) does not hold for methods.
Mark
-Original Message-----
From: Mark Rowell [mailto:[EMAIL PROTECTED]
Sent: 23 October 2003 10:23
To: 'OJB Users List'
Subject: RE: problems with batch-mode=true
Hi
Regarding this issue it looks like (at least as far as RC4 is concerned)
that in the doExecute method of PreparedStatementInvocationHandler.java the
following line (223) gets invoked
((Method) _methods.get(i)).invoke(stmt, (Object[]) _params.get(i));
In my case when using batched mode, and JSQLConnect on MSSqlServer I get a
similar error to Bonnie (java.lang.IllegalArgumentException: object is not
an instance of declaring class)
The methods returned by _methods.get(i) is
public void
org.apache.ojb.broker.platforms.PlatformDefaultImpl.addBatch(java.sql.Prepar
edStatement)
And we are trying to executed it on the statement rather than passing the
platform instance. I think the problem Is in the if statement in that it
does an == rather than a .equals() call to determine whether we want to call
the addBatch method. Now, I do not know whether within a single JVM that the
following Returns true
Method method1 = obj.getClass().getMethod("methodName", ); Method
method2 = obj.getClass().getMethod("methodName", ); method1 ==
method2; // is this gurantee dto be true like it is for instances of Class
e.g.
Obj.getClass() == Obj.getClass() is guranteed to be true?
Regards,
Mark Rowell
-Original Message-
From: Bonnie MacKellar [mailto:[EMAIL PROTECTED]
Sent: 22 October 2003 14:02
To: OJB Users List
Subject: RE: problems with batch-mode=true
Hi,
Here is the code that I tested. You can
see that setBatchMode is called before I start
the tx.
try
{
broker.serviceConnectionManager().setBatchMode(true);
broker.beginTransaction();
for (int i = 0; i < 100; i++)
{
CustomerInterface customer = new Customer();
customer.setCustomerNumber("100" + i);
customer.setFirstName("Big");
customer.setLastName("Customer");
customer.setCustomerName("BadCorporation");
customer.setDeleteTag(Boolean.FALSE);
broker.store(customer);
}
// conMan.executeBatch();
broker.commitTransaction();
}
catch(Exception e)
{
e.printStackTrace();
logger.error(e.getMessage());
broker.abortTransaction();
}
finally
{
broker.close();
}
This chunk of code, exectued with batch-mode="true"
in repository_database.xml, results in the following
two exceptions :
java.lang.IllegalArgumentException: object is not an insta
RE: problems with batch-mode=true
Hi
As a follow on I checked the source for java.lang.reflect.Method and it has
an implementation
Of equals which could possibly indicate tat the equality operator (==) does
not hold for methods.
Mark
-Original Message-
From: Mark Rowell [mailto:[EMAIL PROTECTED]
Sent: 23 October 2003 10:23
To: 'OJB Users List'
Subject: RE: problems with batch-mode=true
Hi
Regarding this issue it looks like (at least as far as RC4 is concerned)
that in the doExecute method of PreparedStatementInvocationHandler.java the
following line (223) gets invoked
((Method) _methods.get(i)).invoke(stmt, (Object[]) _params.get(i));
In my case when using batched mode, and JSQLConnect on MSSqlServer I get a
similar error to Bonnie (java.lang.IllegalArgumentException: object is not
an instance of declaring class)
The methods returned by _methods.get(i) is
public void
org.apache.ojb.broker.platforms.PlatformDefaultImpl.addBatch(java.sql.Prepar
edStatement)
And we are trying to executed it on the statement rather than passing the
platform instance. I think the problem Is in the if statement in that it
does an == rather than a .equals() call to determine whether we want to call
the addBatch method. Now, I do not know whether within a single JVM that the
following Returns true
Method method1 = obj.getClass().getMethod("methodName", ); Method
method2 = obj.getClass().getMethod("methodName", ); method1 ==
method2; // is this gurantee dto be true like it is for instances of Class
e.g.
Obj.getClass() == Obj.getClass() is guranteed to be true?
Regards,
Mark Rowell
-Original Message-
From: Bonnie MacKellar [mailto:[EMAIL PROTECTED]
Sent: 22 October 2003 14:02
To: OJB Users List
Subject: RE: problems with batch-mode=true
Hi,
Here is the code that I tested. You can
see that setBatchMode is called before I start
the tx.
try
{
broker.serviceConnectionManager().setBatchMode(true);
broker.beginTransaction();
for (int i = 0; i < 100; i++)
{
CustomerInterface customer = new Customer();
customer.setCustomerNumber("100" + i);
customer.setFirstName("Big");
customer.setLastName("Customer");
customer.setCustomerName("BadCorporation");
customer.setDeleteTag(Boolean.FALSE);
broker.store(customer);
}
// conMan.executeBatch();
broker.commitTransaction();
}
catch(Exception e)
{
e.printStackTrace();
logger.error(e.getMessage());
broker.abortTransaction();
}
finally
{
broker.close();
}
This chunk of code, exectued with batch-mode="true"
in repository_database.xml, results in the following
two exceptions :
java.lang.IllegalArgumentException: object is not an instance of declaring
class
at java.lang.reflect.Method.invoke(Native Method)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.doExecut
e(Unknown Source)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.invoke(U
nknown Source)
at $Proxy0.doExecute(Unknown Source)
at
org.apache.ojb.broker.util.batch.BatchConnection.executeBatch(Unknown
Source)
at org.apache.ojb.broker.util.batch.BatchConnection.commit(Unknown
Source)
at
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.localCommit(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.commitTransaction(Unknown
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction(Unk
nown Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction(Unk
nown Source)
at
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(CustomerMigrat
ion.java:69)
3425 ERROR [main] dbmigrationutils.CustomerMigration - object is not an
instance of declaring class
3435 DEBUG [main] core.PersistenceBrokerImpl - PB.close was called:
[EMAIL PROTECTED]
org.apache.ojb.broker.TransactionNotInProgressException: ConnectionManager
is NOT in transaction
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.abortTransaction(Unknown
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.abortTransaction(Unkn
own Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.abortTransaction(Unkn
own Source)
at
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(CustomerMigrat
ion.java:75)
Exception in thread "main"
It looks like the persistence broker is being closed down before the call to
abortTransaction
is made. But that does not explain the first exception. This code works
perfectly with
batch-mode="false".
A
RE: problems with batch-mode=true
Hi
Regarding this issue it looks like (at least as far as RC4 is concerned)
that in the doExecute method
of PreparedStatementInvocationHandler.java the following line (223) gets
invoked
((Method) _methods.get(i)).invoke(stmt, (Object[]) _params.get(i));
In my case when using batched mode, and JSQLConnect on MSSqlServer I get a
similar error to
Bonnie (java.lang.IllegalArgumentException: object is not an instance of
declaring class)
The methods returned by _methods.get(i) is
public void
org.apache.ojb.broker.platforms.PlatformDefaultImpl.addBatch(java.sql.Prepar
edStatement)
And we are trying to executed it on the statement rather than passing the
platform instance. I think the problem
Is in the if statement in that it does an == rather than a .equals() call to
determine whether we
want to call the addBatch method. Now, I do not know whether within a single
JVM that the following
Returns true
Method method1 = obj.getClass().getMethod("methodName", );
Method method2 = obj.getClass().getMethod("methodName", );
method1 == method2; // is this gurantee dto be true like it is for instances
of Class e.g.
Obj.getClass() == Obj.getClass() is guranteed to be true?
Regards,
Mark Rowell
-Original Message-
From: Bonnie MacKellar [mailto:[EMAIL PROTECTED]
Sent: 22 October 2003 14:02
To: OJB Users List
Subject: RE: problems with batch-mode=true
Hi,
Here is the code that I tested. You can
see that setBatchMode is called before I start
the tx.
try
{
broker.serviceConnectionManager().setBatchMode(true);
broker.beginTransaction();
for (int i = 0; i < 100; i++)
{
CustomerInterface customer = new Customer();
customer.setCustomerNumber("100" + i);
customer.setFirstName("Big");
customer.setLastName("Customer");
customer.setCustomerName("BadCorporation");
customer.setDeleteTag(Boolean.FALSE);
broker.store(customer);
}
// conMan.executeBatch();
broker.commitTransaction();
}
catch(Exception e)
{
e.printStackTrace();
logger.error(e.getMessage());
broker.abortTransaction();
}
finally
{
broker.close();
}
This chunk of code, exectued with batch-mode="true"
in repository_database.xml, results in the following
two exceptions :
java.lang.IllegalArgumentException: object is not an instance of declaring
class
at java.lang.reflect.Method.invoke(Native Method)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.doExecut
e(Unknown Source)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.invoke(U
nknown Source)
at $Proxy0.doExecute(Unknown Source)
at
org.apache.ojb.broker.util.batch.BatchConnection.executeBatch(Unknown
Source)
at org.apache.ojb.broker.util.batch.BatchConnection.commit(Unknown
Source)
at
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.localCommit(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.commitTransaction(Unknown
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction(Unk
nown Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction(Unk
nown Source)
at
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(CustomerMigrat
ion.java:69)
3425 ERROR [main] dbmigrationutils.CustomerMigration - object is not an
instance of declaring class
3435 DEBUG [main] core.PersistenceBrokerImpl - PB.close was called:
[EMAIL PROTECTED]
org.apache.ojb.broker.TransactionNotInProgressException: ConnectionManager
is NOT in transaction
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.abortTransaction(Unknown
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.abortTransaction(Unkn
own Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.abortTransaction(Unkn
own Source)
at
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(CustomerMigrat
ion.java:75)
Exception in thread "main"
It looks like the persistence broker is being closed down before the call to
abortTransaction
is made. But that does not explain the first exception. This code works
perfectly with
batch-mode="false".
And, if I call executeBatch, I don't get the second exception (the one about
not being in
a transaction), although I still get the first transaction.
I am including my repository_database.xml as an attachment. It is always
possible that
I am doing something terribly wrong there. The relevant jcd-alias is
"ActiveBillStandalone"
thanks,
Bonnie MacKellar
software
Correlated sub-queries
Hi
I have seen various posts regarding aliases in criteria and sub-queries. I
need to perform a correlated
sub-query on a set of objects and I tried using criteria aliases when
building up my queries
but OJB never seems to use them. The objects involved are stored in a single
table and looking at SQL generated by OJB it always uses an alias of A0 for
the outer query and the sub-query.
I am using the criteria.addEqualTo("", ) to
"join" to my subquery
but in the sub-query I need to refer to a field of the outer query (hence
correlated!); -- I
am using RC4. I noticed while web browsing in CVS that some changes have
been made in the last
few days regarding sub-queries -- I am not allowed direct CVS access by our
corporate firewall; hence
does anyone have a code drop from CVS they can send me?
Thanks
Mark Rowell
----
Mark Rowell
CreditTrade
T: +44 (020) 7400 5078
M: mailto:[EMAIL PROTECTED]
CreditTrade Limited is regulated by the FSA. (c) 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 CreditTrades 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.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: OJB and getting a PersistenceBroker instance for a second non-default database
Hi Armin
Oh, on temporarily switching to RC1 my userID/pw problem went away -- they
are specified in the repository file --
I guess that when PBKey was supplied with null userID and password this is
what appears in the debut output for
the repository in 0.9.9.
Many thanks
Mark
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: Friday, March 28, 2003 9:45 AM
To: OJB Users List
Subject: Re: OJB and getting a PersistenceBroker instance for a second
non-default database
Hi Mark,
- Original Message -
From: "Mark Rowell" <[EMAIL PROTECTED]>
To: "'OJB Users List'" <[EMAIL PROTECTED]>
Sent: Friday, March 28, 2003 10:08 AM
Subject: RE: OJB and getting a PersistenceBroker instance for a second
non-default database
> Armin
>
> I am using 0.9.9 as RC1 failed a lot of tests with the JSQLConnect
driver I
> was using (lots of socket closed exceptions
> on SQLServer) -- RC1 unit tests did work with the MS JDBC driver but
that is
> slow, and when returning large numbers
> of "rows" tends to crash my VM (1.4.1_02)
Sounds very strange, maybe a configuration problem.
Do you use the standard settings of OJB config files
(repository + OJB.properties),
where do you use different settings?
I'm a little bit confused, because the stack trace of
your previous post shows an oracle-driver.
> > [java] sub-protocol=oracle
> > [java] db-alias=thin:@165.193.152.53:1521:OPRD_CT1
> > [java] user=
> > [java] password=*
> > [java] eager-release=false
> > [java] ConnectionPoolDescriptor={testOnReturn=false,
The connection descriptor indicate that in your repository file
wasn't set a user. Is this right? If so, you couldn't lookup a PB
instance using PBKey("insight"). Somewhere OJB needs to
know the the user/password.
regards,
Armin
>
> Mark
>
> -Original Message-
> From: Armin Waibel [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 27, 2003 5:50 PM
> To: OJB Users List
> Subject: Re: OJB and getting a PersistenceBroker instance for a second
> non-default database
>
>
> Hi Mark,
>
> I add the following test
>
> public void testPBLookup() throws Exception
> {
> PBKey key = new PBKey(TestHelper.FAR_AWAY_JCD_ALIAS);
> PersistenceBroker broker =
> PersistenceBrokerFactory.createPersistenceBroker(key);
> // get connection to check lookup
> Connection con =
> broker.serviceConnectionManager().getConnection();
> con.isClosed();
> assertNotNull(broker);
> assertEquals(key.getAlias(), broker.getPBKey().getAlias());
> broker.close();
>
> key = new PBKey(TestHelper.DEF_JCD_ALIAS);
> broker =
PersistenceBrokerFactory.createPersistenceBroker(key);
> // get connection to check lookup
> con = broker.serviceConnectionManager().getConnection();
> con.isClosed();
> assertNotNull(broker);
> assertEquals(key.getAlias(), broker.getPBKey().getAlias());
> broker.close();
> }
>
> All works fine.
> Which version do you use?
> Could you post your test case?
>
> regards,
> Armin
>
> - Original Message -
> From: "Mark Rowell" <[EMAIL PROTECTED]>
> To: "'OJB Users List'" <[EMAIL PROTECTED]>
> Sent: Thursday, March 27, 2003 5:44 PM
> Subject: RE: OJB and getting a PersistenceBroker instance for a second
> non-default database
>
>
> > Hi Armin
> >
> > Here is the stack trace; when I create a PBKey specifying the userID
> and
> > password it works just fine.
> >
> > [java] 0 ERROR [main]
> accesslayer.ConnectionFactoryAbstractImpl -
> > Error getting Connection from DriverManager with url
> > (jdbc:oracle:thin:@165.193.152.53:1521:OPRD_CT1) and driver
> > (oracle.jdbc.driver.OracleDriver)
> > [java] java.sql.SQLException: invalid arguments in call
> > [java] at
> > oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
> > [java] at
> > oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:179)
> > [java] at
> > oracle.jdbc.dbaccess.DBError.check_error(DBError.java:1160)
> > [java] at
> > oracle.jdbc.ttc7.TTC7Protocol.logon(TTC7Protocol.java:183)
> > [java] at
> >
oracle.jdbc.driver.OracleConnection.(OracleConnection.java:346)
> > [java] at
> >
>
oracle.jdbc.driver.OracleDriver.getConnectionInstance(OracleDriver.java:
> 468)
> > [java] at
> > oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:314)
> > [java]
RE: OJB and getting a PersistenceBroker instance for a second non-default database
Armin
Sorry - yes that would be confusing; my main DB is SQLServer and I have a
secondary Oracle one; I have just swithced over to RC1 and will run my
tests/app code and see if I get the problem with JSQLConnect; I did send a
mail to the ojb-user list
with details of the failed unit tests with JSQLConnect/SQLServer 2k and RC1
-- straight out of the box --
Mark
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: Friday, March 28, 2003 9:45 AM
To: OJB Users List
Subject: Re: OJB and getting a PersistenceBroker instance for a second
non-default database
Hi Mark,
- Original Message -
From: "Mark Rowell" <[EMAIL PROTECTED]>
To: "'OJB Users List'" <[EMAIL PROTECTED]>
Sent: Friday, March 28, 2003 10:08 AM
Subject: RE: OJB and getting a PersistenceBroker instance for a second
non-default database
> Armin
>
> I am using 0.9.9 as RC1 failed a lot of tests with the JSQLConnect
driver I
> was using (lots of socket closed exceptions
> on SQLServer) -- RC1 unit tests did work with the MS JDBC driver but
that is
> slow, and when returning large numbers
> of "rows" tends to crash my VM (1.4.1_02)
Sounds very strange, maybe a configuration problem.
Do you use the standard settings of OJB config files
(repository + OJB.properties),
where do you use different settings?
I'm a little bit confused, because the stack trace of
your previous post shows an oracle-driver.
> > [java] sub-protocol=oracle
> > [java] db-alias=thin:@165.193.152.53:1521:OPRD_CT1
> > [java] user=
> > [java] password=*
> > [java] eager-release=false
> > [java] ConnectionPoolDescriptor={testOnReturn=false,
The connection descriptor indicate that in your repository file
wasn't set a user. Is this right? If so, you couldn't lookup a PB
instance using PBKey("insight"). Somewhere OJB needs to
know the the user/password.
regards,
Armin
>
> Mark
>
> -Original Message-
> From: Armin Waibel [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 27, 2003 5:50 PM
> To: OJB Users List
> Subject: Re: OJB and getting a PersistenceBroker instance for a second
> non-default database
>
>
> Hi Mark,
>
> I add the following test
>
> public void testPBLookup() throws Exception
> {
> PBKey key = new PBKey(TestHelper.FAR_AWAY_JCD_ALIAS);
> PersistenceBroker broker =
> PersistenceBrokerFactory.createPersistenceBroker(key);
> // get connection to check lookup
> Connection con =
> broker.serviceConnectionManager().getConnection();
> con.isClosed();
> assertNotNull(broker);
> assertEquals(key.getAlias(), broker.getPBKey().getAlias());
> broker.close();
>
> key = new PBKey(TestHelper.DEF_JCD_ALIAS);
> broker =
PersistenceBrokerFactory.createPersistenceBroker(key);
> // get connection to check lookup
> con = broker.serviceConnectionManager().getConnection();
> con.isClosed();
> assertNotNull(broker);
> assertEquals(key.getAlias(), broker.getPBKey().getAlias());
> broker.close();
> }
>
> All works fine.
> Which version do you use?
> Could you post your test case?
>
> regards,
> Armin
>
> - Original Message -
> From: "Mark Rowell" <[EMAIL PROTECTED]>
> To: "'OJB Users List'" <[EMAIL PROTECTED]>
> Sent: Thursday, March 27, 2003 5:44 PM
> Subject: RE: OJB and getting a PersistenceBroker instance for a second
> non-default database
>
>
> > Hi Armin
> >
> > Here is the stack trace; when I create a PBKey specifying the userID
> and
> > password it works just fine.
> >
> > [java] 0 ERROR [main]
> accesslayer.ConnectionFactoryAbstractImpl -
> > Error getting Connection from DriverManager with url
> > (jdbc:oracle:thin:@165.193.152.53:1521:OPRD_CT1) and driver
> > (oracle.jdbc.driver.OracleDriver)
> > [java] java.sql.SQLException: invalid arguments in call
> > [java] at
> > oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
> > [java] at
> > oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:179)
> > [java] at
> > oracle.jdbc.dbaccess.DBError.check_error(DBError.java:1160)
> > [java] at
> > oracle.jdbc.ttc7.TTC7Protocol.logon(TTC7Protocol.java:183)
> > [java] at
> >
oracle.jdbc.driver.OracleConnection.(OracleConnection.java:346)
> > [java] at
> >
>
oracle.jdbc.driver.OracleDriver.getConnectionInstance(OracleDriver.java:
> 468)
> > [java] at
> > oracle.jdbc.driver.OracleDri
RE: OJB and getting a PersistenceBroker instance for a second non-default database
Armin
I am using 0.9.9 as RC1 failed a lot of tests with the JSQLConnect driver I
was using (lots of socket closed exceptions
on SQLServer) -- RC1 unit tests did work with the MS JDBC driver but that is
slow, and when returning large numbers
of "rows" tends to crash my VM (1.4.1_02)
Mark
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 27, 2003 5:50 PM
To: OJB Users List
Subject: Re: OJB and getting a PersistenceBroker instance for a second
non-default database
Hi Mark,
I add the following test
public void testPBLookup() throws Exception
{
PBKey key = new PBKey(TestHelper.FAR_AWAY_JCD_ALIAS);
PersistenceBroker broker =
PersistenceBrokerFactory.createPersistenceBroker(key);
// get connection to check lookup
Connection con =
broker.serviceConnectionManager().getConnection();
con.isClosed();
assertNotNull(broker);
assertEquals(key.getAlias(), broker.getPBKey().getAlias());
broker.close();
key = new PBKey(TestHelper.DEF_JCD_ALIAS);
broker = PersistenceBrokerFactory.createPersistenceBroker(key);
// get connection to check lookup
con = broker.serviceConnectionManager().getConnection();
con.isClosed();
assertNotNull(broker);
assertEquals(key.getAlias(), broker.getPBKey().getAlias());
broker.close();
}
All works fine.
Which version do you use?
Could you post your test case?
regards,
Armin
- Original Message -----
From: "Mark Rowell" <[EMAIL PROTECTED]>
To: "'OJB Users List'" <[EMAIL PROTECTED]>
Sent: Thursday, March 27, 2003 5:44 PM
Subject: RE: OJB and getting a PersistenceBroker instance for a second
non-default database
> Hi Armin
>
> Here is the stack trace; when I create a PBKey specifying the userID
and
> password it works just fine.
>
> [java] 0 ERROR [main]
accesslayer.ConnectionFactoryAbstractImpl -
> Error getting Connection from DriverManager with url
> (jdbc:oracle:thin:@165.193.152.53:1521:OPRD_CT1) and driver
> (oracle.jdbc.driver.OracleDriver)
> [java] java.sql.SQLException: invalid arguments in call
> [java] at
> oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
> [java] at
> oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:179)
> [java] at
> oracle.jdbc.dbaccess.DBError.check_error(DBError.java:1160)
> [java] at
> oracle.jdbc.ttc7.TTC7Protocol.logon(TTC7Protocol.java:183)
> [java] at
> oracle.jdbc.driver.OracleConnection.(OracleConnection.java:346)
> [java] at
>
oracle.jdbc.driver.OracleDriver.getConnectionInstance(OracleDriver.java:
468)
> [java] at
> oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:314)
> [java] at
> java.sql.DriverManager.getConnection(DriverManager.java:512)
> [java] at
> java.sql.DriverManager.getConnection(DriverManager.java:193)
> [java] at
>
org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.newConne
ctio
> nFromDriverManager(ConnectionFactoryAbstractImpl.java:236)
> [java] at
>
org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl$ConPoolFac
tory
> .makeObject(ConnectionFactoryPooledImpl.java:205)
> [java] at
> org.apache.commons.pool.impl.GenericObjectPool.borrowObject(Unknown
Source)
> [java] at
>
org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl.getConnect
ionF
> romPool(ConnectionFactoryPooledImpl.java:65)
> [java] at
>
org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.lookupCo
nnec
> tion(ConnectionFactoryAbstractImpl.java:101)
> [java] at
>
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.getConnection(Co
nnec
> tionManagerImpl.java:129)
> [java] at
>
org.apache.ojb.broker.accesslayer.StatementManager.getPreparedStatement(
Stat
> ementManager.java:711)
> [java] at
>
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(JdbcAccess
Impl
> .java:261)
> [java] at
>
org.apache.ojb.broker.accesslayer.RsIterator.(RsIterator.java:175)
> [java] at
>
org.apache.ojb.broker.singlevm.RsIteratorFactoryImpl.createRsIterator(Rs
Iter
> atorFactoryImpl.java:95)
> [java] at
>
org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getRsIteratorFromQu
ery(
> PersistenceBrokerImpl.java:2156)
> [java] at
>
org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getIteratorFromQuer
y(Pe
> rsistenceBrokerImpl.java:1550)
> [java] at
>
org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getIteratorByQuery(
Pers
> istenceBrokerImpl.java:1536)
> [java] at
>
org.apache.ojb.broker.singlevm.DelegatingPersistenceBroker.getIteratorBy
Quer
> y(DelegatingPersistenceBroker.java:278)
> [java] at
> com.credittrade.market.C
RE: OJB and getting a PersistenceBroker instance for a second non-default database
:193) [java] at org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.newConnectio nFromDriverManager(ConnectionFactoryAbstractImpl.java:236) [java] ... 14 more And here is my repository fragment (I have x'ed out the userID and password as this is a live database!) Many thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2003 4:23 PM To: OJB Users List Subject: Re: OJB and getting a PersistenceBroker instance for a second non-default database Hi Mark, > I tried the single argument constructor for PBKey but no joy. this should be possible, could you post an example and the resulting stack trace? regards, Armin - Original Message - From: "Mark Rowell" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, March 27, 2003 5:00 PM Subject: OJB and getting a PersistenceBroker instance for a second non-default database > Hi > > I know I can get a default PB instance using defaultPersistenceBroker on > PBFactory and that for a second database I can get a broker if I specify the > alias and the userID and password > to use for the second repositiry, but is there a way of getting a broker > instance for the second database whereby it picks up the userID and password > specified in the repository file? > > I tried the single argument constructor for PBKey but no joy. > > Thanks > > Mark > > > Mark Rowell > CreditTrade > > T: +44 (020) 7400 5078 > M: mailto:[EMAIL PROTECTED] > > CreditTrade Limited is regulated by the FSA. (c) 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 CreditTrades 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. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) 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 CreditTrades 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
OJB and getting a PersistenceBroker instance for a second non-default database
Hi I know I can get a default PB instance using defaultPersistenceBroker on PBFactory and that for a second database I can get a broker if I specify the alias and the userID and password to use for the second repositiry, but is there a way of getting a broker instance for the second database whereby it picks up the userID and password specified in the repository file? I tried the single argument constructor for PBKey but no joy. Thanks Mark Mark Rowell CreditTrade T: +44 (020) 7400 5078 M: mailto:[EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) 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 CreditTrades 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Persistence brokers and threads..(again)
Hi I asked this question a couple of days ago. Up to now I have been managing my own persistence broker/thread mapping; I noticed that there is a persitence broker thread mapping class in the distribution for RC1. >From looking at the code I cant see how the roker/thread mapping works as the only reference to a persistence broker thread mapping is in PersistenceBrokerThreadMapping class, which is used in the PersistenceBrokerFactoryDefaultImpl class but only in the methods activateObject/passivateObject which is not called in any other code in the distribution. Questions are: - am I mistaken... - if so, does this all happen by default - or, should I still perform my own thread/broker management. Regards Mark Rowell ---- Mark Rowell CreditTrade T: +44 (020) 7400 5078 M: mailto:[EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) 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 CreditTrades 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ThreadLocal and PersistenceBroker
Hi Previsouly to RC1 and 0.9.9 etc I was using my own ThreadLocal class to manage PersistenceBroker instances on a per thread basis. Does OJB do this now in RC1? If this ThreadLocal mapping exists does it close() the PersistenceBroker on thread finalization, thereby returning it to the pool? Regards, Mark Rowell Mark Rowell CreditTrade T: +44 (020) 7400 5078 M: mailto:[EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) 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 CreditTrades 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Date criteria
Hi Scott
are you using field conversions on your date columns? This may be why what
you are trying to do is "not working".
Regards,
Mark Rowell
-Original Message-
From: Scott W. Hill [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 04, 2003 10:59 PM
To: ojB List
Subject: Date criteria
I'm trying to do something like:
select * from contributions where last_activity >= '2003-03-04
14:35:38';
but using this:
criteria.addGreaterOrEqualThanField("lastActivity", date); or
criteria.addGreaterOrEqualThanField("lastActivity",
formatter.format(date));
doesn't work. Any ideas?
--Scott
--Scott
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
CreditTrade Limited is regulated by the FSA. (c) 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 CreditTrades 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.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RC1 Junit test results for SQL Server
d] context:[(2) [Thread[main,5,main], IO:a73bf, Dbc:1429]]] com.jnetdirect.jsql.x: DBComms.transmit exception:[java.net.SocketException: Socket closed] context:[(2) [Thread[main,5,main], IO:a73bf, Dbc:1429]]] at com.jnetdirect.jsql.h.a(Unknown Source) at com.jnetdirect.jsql.au.a(Unknown Source) at com.jnetdirect.jsql.ah.new(Unknown Source) at com.jnetdirect.jsql.ah.do(Unknown Source) at com.jnetdirect.jsql.ap.executeQuery(Unknown Source) at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(JdbcAccessImpl .java:259) at org.apache.ojb.broker.accesslayer.RsIterator.(RsIterator.java:175) at org.apache.ojb.broker.accesslayer.ReportQueryRsIterator.(ReportQueryRs Iterator.java:86) at org.apache.ojb.broker.singlevm.ReportRsIteratorFactoryImpl.createRsIterator( ReportRsIteratorFactoryImpl.java:96) at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getRsIteratorFromQuery( PersistenceBrokerImpl.java:2215) at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getReportQueryIteratorF romQuery(PersistenceBrokerImpl.java:2263) at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getReportQueryIteratorB yQuery(PersistenceBrokerImpl.java:2192) at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getCount(PersistenceBro kerImpl.java:2163) at org.apache.ojb.broker.singlevm.DelegatingPersistenceBroker.getCount(Delegati ngPersistenceBroker.java:305) at org.apache.ojb.broker.metadata.MetadataTest.testLookupPB1(MetadataTest.java: 139) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) rethrown as org.apache.ojb.broker.PersistenceBrokerSQLException: DBComms.transmit exception:[java.net.SocketException: Socket closed] context:[(2) [Thread[main,5,main], IO:a73bf, Dbc:1429]]] at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(JdbcAccessImpl .java:302) at org.apache.ojb.broker.accesslayer.RsIterator.(RsIterator.java:175) at org.apache.ojb.broker.accesslayer.ReportQueryRsIterator.(ReportQueryRs Iterator.java:86) at org.apache.ojb.broker.singlevm.ReportRsIteratorFactoryImpl.createRsIterator( ReportRsIteratorFactoryImpl.java:96) at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getRsIteratorFromQuery( PersistenceBrokerImpl.java:2215) at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getReportQueryIteratorF romQuery(PersistenceBrokerImpl.java:2263) at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getReportQueryIteratorB yQuery(PersistenceBrokerImpl.java:2192) at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getCount(PersistenceBro kerImpl.java:2163) at org.apache.ojb.broker.singlevm.DelegatingPersistenceBroker.getCount(Delegati ngPersistenceBroker.java:305) at org.apache.ojb.broker.metadata.MetadataTest.testLookupPB1(MetadataTest.java: 139) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) Caused by: com.jnetdirect.jsql.x: DBComms.transmit exception:[java.net.SocketException: Socket closed] context:[(2) [Thread[main,5,main], IO:a73bf, Dbc:1429]]] at com.jnetdirect.jsql.h.a(Unknown Source) at com.jnetdirect.jsql.au.a(Unknown Source) at com.jnetdirect.jsql.ah.new(Unknown Source) at com.jnetdirect.jsql.ah.do(Unknown Source) at com.jnetdirect.jsql.ap.executeQuery(Unknown Source) at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(JdbcAccessImpl .java:259) ... 25 more I hope that helps Regards, Mark Rowell -------- Mark Rowell CreditTrade T: +44 (020) 7400 5078 M: mailto:[EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) 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 CreditTrades 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 recommen
RE: Report queries on extents
Hi Jakob
I suspected as much -- the only reason I have been using column names was
that in previous versions of OJB using field names in criteria
with non-simple types (e.g. ones that require field conversions) the
conversions did not seem to take place so I was forced to use column names
in criteria
and do the conversions myself. Now of course (v 0.9.9) it all seems to work.
Thanks
Mark
-Original Message-
From: Jakob Braeuchi [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 26, 2003 9:03 PM
To: OJB Users List
Subject: Re: Report queries on extents
hi mark,
i haven't run your testcase yet, but i think i found the problem.
the 'columns' you look for in your report-query should be
attribute-names NOT database-columns-names.
in your case 'pk' instead of 'PK'. attribute-names will be translated
into database-column-names by the SqlGenerator and will be prefixed with
a table alias (pk -> A1.PK).
if you use database-column-names in the query the SqlTranslator cannot
find field-definitions matching those names and passes them unmodified
to the sql-string (no alias added: PK -> PK).
imo we should improve the docs to clearly show the difference between
database-column-names and attribute-names :)
Mark Rowell wrote:
>Jakob
>
>I have a test case to show my problem
>
>public void testReportQuery() {
>testDeleteContractVersionEffectiveness();
>createTestData();
>
>Query query = QueryFactory.newReportQuery(Version.class, new
>String[]{"PK","contract.PK","contract.contractValue1"}, null, false);
>Iterator iter = broker.getReportQueryIteratorByQuery(query);
>int rowCount = 0;
>while ( iter.hasNext() ) {
>rowCount++;
>}
>
>assertTrue("Expected to get " + COUNT + " rows in the report query.
>Got " + rowCount + " instead.", rowCount == COUNT);
>}
>
>Add it to the ContractVersionEffectivenessTest class. I had to chage the
>primary key column names to PK from pk in
>reposotory_junit.xml for the three mappings involved thus:
>
>
>class="org.apache.ojb.broker.Contract"
> table="Contract"
> >
> name="pk"
>column="PK"
>jdbc-type="VARCHAR"
>primarykey="true"
>autoincrement="false"
> />
>name="contractValue1"
> column="contract_value1"
> jdbc-type="VARCHAR"
> />
> name="contractValue2"
>column="contract_value2"
>jdbc-type="INTEGER"
> />
>name="contractValue3"
> column="contract_value3"
> jdbc-type="VARCHAR"
> />
>name="contractValue4"
> column="contract_value4"
> jdbc-type="TIMESTAMP"
> />
>name="fkToRelated"
> column="fk_to_related"
> jdbc-type="VARCHAR"
> />
> name="relatedToContract"
> class-ref="org.apache.ojb.broker.RelatedToContract"
> >
>
>
>
>
> class="org.apache.ojb.broker.RelatedToContract"
> table="RelatedToContract"
>>
> name="pk"
>column="PK"
>jdbc-type="VARCHAR"
>primarykey="true"
>autoincrement="false"
> />
>name="relatedValue1"
> column="relatedValue1"
> jdbc-type="VARCHAR"
> />
> name="relatedValue2"
>column="relatedValue2"
>jdbc-type="INTEGER"
> />
>name="relatedValue3"
> column="relatedValue3"
> jdbc-type="TIMESTAMP"
> />
>
>
> class="org.apache.ojb.broker.Version"
> table="Version"
>>
> name="pk"
>column="PK"
>jdbc-type="VARCHAR"
>primarykey="true"
>autoincrement="false"
> />
>name="versionValue1"
> column="version_value1"
> jdbc-type="VARCHAR"
> />
> name="versionValue2"
>column="version_value2"
>jdbc-type="INTEGER"
> />
>name=&q
Question re prefetched relationsbips
Hi
Does anyone know if prefetched relationships can reach more than one "layer"
of references/collections from an class being queried?
E.g. If I have a class A that I an querying and it has a 1:m relationship
with some class B, with the relationship defined by the name "allb",
and then each B has 1 1:1 relationsbip with another class C, with the
relationship called "singlec", is the following supposed to work:
Criteria criteria = new Criteria();
// configure the criteria
...
// add prefetched relationships
criteria.addPrefetchedRelationship("allb");
criteria.addPrefetchedRelationship("allb.singlec");
Query q = QueryFactory.newQuery( A.class, criteria);
I can get the single layer if indirection (e.g.
criteria.addPrefetchedRelationship("allb")) to work, but when I try the
above I get
an error message from OJB saying that it cant find the relationship
"allb.singlec". One thing to not is that I can specify query criteria
on this 2 level relationship i.e.
criteria.addEqualTo("allb.singlec.somefield", "test value");
where somefield is a field in the class C.
Regards,
Mark Rowell
Mark Rowell
CreditTrade
T: +44 (020) 7400 5078
M: mailto:[EMAIL PROTECTED]
CreditTrade Limited is regulated by the FSA. (c) 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 CreditTrades 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.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: ClassCastException persisting Date field
John You may need to use a FieldConversion on the relevant field(s)/columns(s) e.g Mark -Original Message- From: O'Reilly John [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 25, 2003 10:38 AM To: 'OJB Users List' Subject: ClassCastException persisting Date field Hi, Is there any known issue with persisting Date's using OJB. I have defined the field as follows: The code that sets the date is as follows: Calendar today = Calendar.getInstance() ; today.set(Calendar.DAY_OF_MONTH, 28 ); today.set(Calendar.MONTH, 8 ); today.set(Calendar.YEAR, 2000); productModel.setIntendedDateOfRelease( today.getTime() ); When I try to persist the productModel object I get a ClassCastException (as shown below). I noticed that when I load an existing object from the db the type of the field is java.sql.Date (subclass of java.util.Date) whereas the type of the field I'm persisting is actaully a java.util.Date. Rgds, John java.lang.ClassCastException: java.util.Dateat oracle.jdbc.driver.OraclePreparedStatement.setObject(OraclePreparedStatement .java:2051) at oracle.jdbc.driver.OraclePreparedStatement.setObject(OraclePreparedStatement .java:2102) at com.p6spy.engine.spy.P6PreparedStatement.setObject(P6PreparedStatement.java: 282)at org.apache.ojb.broker.platforms.PlatformDefaultImpl.setObjectForStatement(Pl atformDefaultImpl.java:229) at org.apache.ojb.broker.platforms.PlatformOracleImpl.setObjectForStatement(Pla tformOracleImpl.java:126) at org.apache.ojb.broker.accesslayer.StatementManager.bindInsert(StatementManag er.java:511)at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeInsert(JdbcAccessImp l.java:198) at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.storeToDb(PersistenceBr okerImpl.java:1742) at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.store(PersistenceBroker Impl.java:1683) at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.store(PersistenceBroker Impl.java:632) at org.apache.ojb.broker.singlevm.DelegatingPersistenceBroker.store(DelegatingP ersistenceBroker.java:151) at ie.mcps.product.dao.ProductDAO.addProduct(ProductDAO.java:65) at ie.mcps.product.dao.ProductDAOTest.testAddProduct(ProductDAOTest.java:191) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:166) at junit.framework.TestCase.runBare(TestCase.java:140) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124)at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:131) at junit.framework.TestSuite.runTest(TestSuite.java:173) at junit.framework.TestSuite.run(TestSuite.java:168) at com.borland.jbuilder.unittest.JBTestRunner.run(JBTestRunner.java:161) at com.borland.jbuilder.unittest.JBTestRunner.initiateTest(JBTestRunner.java:19 4) at com.borland.jbuilder.unittest.JBTestRunner.main(JBTestRunner.java:486) This e-mail and any files transmitted with it are confidential and may be privileged and are intended solely for the individual named/ for the use of the individual or entity to whom they are addressed.If you are not the intended addressee, you should not disseminate, distribute or copy this e-mail.Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system.If you are not the intended recipient, you are notified that reviewing, disclosing, copying, distributing or taking any action in reliance on the contents of this e-mail is strictly prohibited.Please note that any views or opinions expressed in this e-mail are solely those of the author and do not necessarily represent those of Traventec Limited.E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, or arrive late or incomplete.Traventec Limited therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.The recipient should check this e-mail and any attachments for the presence of viruses.This e-mail has been swept for computer viruses however Traventec Limited accepts no liability for any damage caused by any virus transmitted by this e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) 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 co
RE: Report queries on extents
Jakob
I have a test case to show my problem
public void testReportQuery() {
testDeleteContractVersionEffectiveness();
createTestData();
Query query = QueryFactory.newReportQuery(Version.class, new
String[]{"PK","contract.PK","contract.contractValue1"}, null, false);
Iterator iter = broker.getReportQueryIteratorByQuery(query);
int rowCount = 0;
while ( iter.hasNext() ) {
rowCount++;
}
assertTrue("Expected to get " + COUNT + " rows in the report query.
Got " + rowCount + " instead.", rowCount == COUNT);
}
Add it to the ContractVersionEffectivenessTest class. I had to chage the
primary key column names to PK from pk in
reposotory_junit.xml for the three mappings involved thus:
If I use the field names in the report query (e.g. lower case 'pk') if works
fine. Using upper case values (e.g. 'PK')
and the database (in my case SQLServer) I get the following stack trace:
[org.apache.ojb.broker.accesslayer.JdbcAccessImpl] ERROR: SQLException
during the execution of the query (for a org.apache.ojb.broker.Version):
[Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]Ambiguous column name
'pk'.
[Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]Ambiguous column name
'pk'.
java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for
JDBC][SQLServer]Ambiguous column name 'pk'.
at com.microsoft.jdbc.base.BaseExceptions.createException(Unknown
Source)
at com.microsoft.jdbc.base.BaseExceptions.getException(Unknown Source)
at com.microsoft.jdbc.sqlserver.tds.TDSRequest.processErrorToken(Unknown
Source)
at com.microsoft.jdbc.sqlserver.tds.TDSRequest.processReplyToken(Unknown
Source)
at
com.microsoft.jdbc.sqlserver.tds.TDSRPCRequest.processReplyToken(Unknown
Source)
at com.microsoft.jdbc.sqlserver.tds.TDSRequest.processReply(Unknown
Source)
at com.microsoft.jdbc.sqlserver.tds.TDSCursorRequest.openCursor(Unknown
Source)
at com.microsoft.jdbc.sqlserver.SQLServerImplStatement.execute(Unknown
Source)
at com.microsoft.jdbc.base.BaseStatement.commonExecute(Unknown Source)
at com.microsoft.jdbc.base.BaseStatement.executeQueryInternal(Unknown
Source)
at com.microsoft.jdbc.base.BasePreparedStatement.executeQuery(Unknown
Source)
at
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(JdbcAccessImpl
.java:291)
at
org.apache.ojb.broker.accesslayer.RsIterator.(RsIterator.java:175)
at
org.apache.ojb.broker.accesslayer.ReportQueryRsIterator.(ReportQueryRs
Iterator.java:86)
at
org.apache.ojb.broker.singlevm.ReportRsIteratorFactoryImpl.createRsIterator(
ReportRsIteratorFactoryImpl.java:96)
at
org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getRsIteratorFromQuery(
PersistenceBrokerImpl.java:2147)
at
org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getReportQueryIteratorF
romQuery(PersistenceBrokerImpl.java:2195)
at
org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getReportQueryIteratorB
yQuery(PersistenceBrokerImpl.java:2124)
at
org.apache.ojb.broker.singlevm.DelegatingPersistenceBroker.getReportQueryIte
ratorByQuery(DelegatingPersistenceBroker.java:273)
at
org.apache.ojb.broker.ContractVersionEffectivenessTest.testReportQuery(Contr
actVersionEffectivenessTest.java:184)
and the following generated SQL:
[junit] [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl]
DEBUG: SQL: SELECT PK,PK,A1.contract_value1 FROM Version A0 LEFT OUTER JOIN
Contract A1 ON A0.fk_to_contract=A1.PK
I hope that helps!
Mark
BTW -- what is the "policy" on selecting our by field name or column name
and filtering by the same?
-Original Message-
From: Jakob Braeuchi [mailto:[EMAIL PROTECTED]
Sent: Friday, February 21, 2003 4:41 PM
To: OJB Users List
Subject: Re: Report queries on extents
hi mark,
yes, please send me the testcase. if it's based on our testclasses it
would be perfect.
jakob
Mark Rowell wrote:
>Hi Jakob
>
>Some news on this problem -- it turns out it is a case sensitivity issue.
>E.g. If I query on the column name in the report
>query (e.g. upper case 'ID') it does not work, if I query on the field name
>(e.g. lower case 'id') it works.
>
>N.B. this therefore is only a problem where we have 2 columns in the query
>with the same names on different tables. E.g. if I query by
>column name rather than field name the sql generator strips off any
>qualification I put in.
>
>I do have some new classes/data/tests that show this.
>Do you want me to send them to you?
>
>Mark
>-Original Message--
RE: Report queries on extents
Hi Jakob
Some news on this problem -- it turns out it is a case sensitivity issue.
E.g. If I query on the column name in the report
query (e.g. upper case 'ID') it does not work, if I query on the field name
(e.g. lower case 'id') it works.
N.B. this therefore is only a problem where we have 2 columns in the query
with the same names on different tables. E.g. if I query by
column name rather than field name the sql generator strips off any
qualification I put in.
I do have some new classes/data/tests that show this.
Do you want me to send them to you?
Mark
-Original Message-
From: Jakob Braeuchi [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 19, 2003 6:25 PM
To: OJB Users List
Subject: Re: Report queries on extents
hi mark,
i forgot to ask whether you coukd adapt my test case so it matches the
one you have problems with ?
jakob
Mark Rowell wrote:
>Hi Jakob
>
>Thanks for that but my generated SQL does not qualify the columns I was
>selecting and hence
>I get a non unique name for the ID column reported by SQL Server. One
>difference between the example you give and
>my example is that my criteria filters on a couple of values in a
collection
>attribute of the class I am querying.
>E.g. to extend the example you give:
>
>public void testReportPathExpressionForExtents()
>{
>ArrayList list = new java.util.ArrayList();
>
>Criteria crit = new Criteria();
>crit.addEqualTo("groupId", new Integer(5));
>crit.addEqualTo("allArticlesInGroup.articleName", "some name");
>
>ReportQueryByCriteria q =
>QueryFactory.newReportQuery(ProductGroup.class, crit, true);
>q.setColumns(new String[]{"groupId", "groupName",
>"allArticlesInGroup.articleId", "allArticlesInGroup.articleName"});
>
>Iterator iter = broker.getReportQueryIteratorByQuery(q);
>while (iter.hasNext())
>
>Additionally, is ProductGroup an extent? The class I query is the top level
>of an extent.
>
>I will make a change to the test you give so it looks like my query and
then
>see what results I get.
>I will also send you the generated SQL.
>
>Regards & thanks
>
>Mark
>
>
>-Original Message-
>From: Jakob Braeuchi [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, February 19, 2003 4:48 PM
>To: OJB Users List
>Subject: Re: Report queries on extents
>
>
>hi mark,
>
>yes, report queries are extent aware. the method below is taken from the
>testcase QueryTest and it produces the query shown further down.
>
>public void testReportPathExpressionForExtents()
>{
>ArrayList list = new java.util.ArrayList();
>
>Criteria crit = new Criteria();
>crit.addEqualTo("groupId", new Integer(5));
>
>ReportQueryByCriteria q =
>QueryFactory.newReportQuery(ProductGroup.class, crit, true);
>q.setColumns(new String[]{"groupId", "groupName",
>"allArticlesInGroup.articleId", "allArticlesInGroup.articleName"});
>
>Iterator iter = broker.getReportQueryIteratorByQuery(q);
>while (iter.hasNext())
>{
>list.add(iter.next());
>}
>
>// 7 Articles, 2 Books, 3 Cds
>assertEquals("check size", list.size(), 7);
>}
>
>SELECT DISTINCT
>A0.Kategorie_Nr,A0.KategorieName,A1.Artikel_Nr,A1.Artikelname FROM
>Kategorien A0 LEFT OUTER JOIN Artikel A1 ON
>A0.Kategorie_Nr=A1.Kategorie_Nr LEFT OUTER JOIN BOOKS A1E0 ON
>A0.Kategorie_Nr=A1E0.Kategorie_Nr LEFT OUTER JOIN CDS A1E1 ON
>A0.Kategorie_Nr=A1E1.Kategorie_Nr WHERE A0.Kategorie_Nr = '5'
>
>hth
>jakob
>
>Mark Rowell wrote:
>
>
>
>>Hi
>>
>>I was wondering if report queries on extents work where I am selecting out
>>a/some column(s) from a table
>>related to the extent classes. A concrete example may help (!)
>>
>>I have an extent class called Bond with concrete implementations called
>>FixedCouponBond and FRN.
>>There is a 1 to n relationship a single Bond and the priceDetails class
>>(which is concrete). In my
>>repository_user.xml file they mappings are setup as follows (I only show
>>themapping for the FixedCouponBond class
>>as it is identical for the FRN class)
>>
>> >class="com.credittrade.instruments.securities.BBGBondModel"
>>
>>table="Bonds"
>> >
>> >name="id"
>>column="ID"
>>jdbc-type="INTEGER"
>>primarykey="true"
>>autoincrement="true"
RE: Problem with prefetched relationships on extents (and a fix!)
Hi, Just to follow up again, could someone patch CVS -- I dont have access... Regards, Mark -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 20, 2003 12:02 PM To: '[EMAIL PROTECTED]' Subject: Problem with prefetched relationships on extents (and a fix!) Hi I had a problem with prefetched relationships for collections, where the owner of a collection in a relationship is a class that is part of an extent. It manifested itself by when I tried to access the collection in an owner it always had size of zero. I tracked down the problem to CollectionPrefetcher where it gets the owner by identity using the foreign key in the item class in the collection. It was creating an instance of Identity using the real class of the object whereas in RsIterator the owner instance is cached using the top level class in the extent (as the primary keys must be unique across all concrete classes in an extent). Hence I change CollectionPrefetcher thus in the associatedBatched method of CollectionPrefetcher: Existing line of code id = new Identity(getOwnerClassDescriptor().getClassOfObject(), fkValues); Change it to id = new Identity( getBroker().getTopLevelClass(getOwnerClassDescriptor().getClassOfObject()), fkValues ); and collection prefetch should work for all types of owner both concrete and part of an extent. I havent checked the 1:1 relationship prefetcher. As a side not this analysis could have remifications for other places in the code where a new Identity() instance is created. Regards, Mark Rowell ---- Mark Rowell CreditTrade T: +44 (020) 7400 5078 M: mailto:[EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) 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 CreditTrades 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) 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 CreditTrades 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Question about storing new items in collection and have the owner of the collection automatically refreshed...
Hi I have a question re adding instances to collections and the owner of the collection automatically picking up the new instance. I have 2 classes, the owner is Instrument (super-interface of an extent) and the collection item class is PriceDetails. The steps I follow are 1) Get the instrument instance 2) Create a new priceDetails instance and store it using persistence broker 3) Access the new instance in the instrument class. When I attempt step 3 the PriceDetails instance I stored in the database is not there. I have the following settings inthe repository XML file For the collection descriptor for price details in the instrument class I have auto-retrieve="true" auto-update="false" auto-delete="false" proxy="true" refresh="true" To get (3) to work, e.g. have my owner instance automatically pickup the new pricedetails item is there anything else I have to do? Regards, Mark Rowell -------- Mark Rowell CreditTrade T: +44 (020) 7400 5078 M: mailto:[EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) 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 CreditTrades 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with prefetched relationships on extents (and a fix!)
Hi again As an addition to this email, would it not be better to have a factory method on PersistenceBroker that could construct a new Identity given an object? Mark -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 20, 2003 12:02 PM To: '[EMAIL PROTECTED]' Subject: Problem with prefetched relationships on extents (and a fix!) Hi I had a problem with prefetched relationships for collections, where the owner of a collection in a relationship is a class that is part of an extent. It manifested itself by when I tried to access the collection in an owner it always had size of zero. I tracked down the problem to CollectionPrefetcher where it gets the owner by identity using the foreign key in the item class in the collection. It was creating an instance of Identity using the real class of the object whereas in RsIterator the owner instance is cached using the top level class in the extent (as the primary keys must be unique across all concrete classes in an extent). Hence I change CollectionPrefetcher thus in the associatedBatched method of CollectionPrefetcher: Existing line of code id = new Identity(getOwnerClassDescriptor().getClassOfObject(), fkValues); Change it to id = new Identity( getBroker().getTopLevelClass(getOwnerClassDescriptor().getClassOfObject()), fkValues ); and collection prefetch should work for all types of owner both concrete and part of an extent. I havent checked the 1:1 relationship prefetcher. As a side not this analysis could have remifications for other places in the code where a new Identity() instance is created. Regards, Mark Rowell ---- Mark Rowell CreditTrade T: +44 (020) 7400 5078 M: mailto:[EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) 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 CreditTrades 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) 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 CreditTrades 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem with prefetched relationships on extents (and a fix!)
Hi I had a problem with prefetched relationships for collections, where the owner of a collection in a relationship is a class that is part of an extent. It manifested itself by when I tried to access the collection in an owner it always had size of zero. I tracked down the problem to CollectionPrefetcher where it gets the owner by identity using the foreign key in the item class in the collection. It was creating an instance of Identity using the real class of the object whereas in RsIterator the owner instance is cached using the top level class in the extent (as the primary keys must be unique across all concrete classes in an extent). Hence I change CollectionPrefetcher thus in the associatedBatched method of CollectionPrefetcher: Existing line of code id = new Identity(getOwnerClassDescriptor().getClassOfObject(), fkValues); Change it to id = new Identity( getBroker().getTopLevelClass(getOwnerClassDescriptor().getClassOfObject()), fkValues ); and collection prefetch should work for all types of owner both concrete and part of an extent. I havent checked the 1:1 relationship prefetcher. As a side not this analysis could have remifications for other places in the code where a new Identity() instance is created. Regards, Mark Rowell Mark Rowell CreditTrade T: +44 (020) 7400 5078 M: mailto:[EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) 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 CreditTrades 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Report queries on extents
Will do...
All the best
Mark
-Original Message-
From: Jakob Braeuchi [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 19, 2003 6:25 PM
To: OJB Users List
Subject: Re: Report queries on extents
hi mark,
i forgot to ask whether you coukd adapt my test case so it matches the
one you have problems with ?
jakob
Mark Rowell wrote:
>Hi Jakob
>
>Thanks for that but my generated SQL does not qualify the columns I was
>selecting and hence
>I get a non unique name for the ID column reported by SQL Server. One
>difference between the example you give and
>my example is that my criteria filters on a couple of values in a
collection
>attribute of the class I am querying.
>E.g. to extend the example you give:
>
>public void testReportPathExpressionForExtents()
>{
>ArrayList list = new java.util.ArrayList();
>
>Criteria crit = new Criteria();
>crit.addEqualTo("groupId", new Integer(5));
>crit.addEqualTo("allArticlesInGroup.articleName", "some name");
>
>ReportQueryByCriteria q =
>QueryFactory.newReportQuery(ProductGroup.class, crit, true);
>q.setColumns(new String[]{"groupId", "groupName",
>"allArticlesInGroup.articleId", "allArticlesInGroup.articleName"});
>
>Iterator iter = broker.getReportQueryIteratorByQuery(q);
>while (iter.hasNext())
>
>Additionally, is ProductGroup an extent? The class I query is the top level
>of an extent.
>
>I will make a change to the test you give so it looks like my query and
then
>see what results I get.
>I will also send you the generated SQL.
>
>Regards & thanks
>
>Mark
>
>
>-Original Message-
>From: Jakob Braeuchi [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, February 19, 2003 4:48 PM
>To: OJB Users List
>Subject: Re: Report queries on extents
>
>
>hi mark,
>
>yes, report queries are extent aware. the method below is taken from the
>testcase QueryTest and it produces the query shown further down.
>
>public void testReportPathExpressionForExtents()
>{
>ArrayList list = new java.util.ArrayList();
>
>Criteria crit = new Criteria();
>crit.addEqualTo("groupId", new Integer(5));
>
>ReportQueryByCriteria q =
>QueryFactory.newReportQuery(ProductGroup.class, crit, true);
>q.setColumns(new String[]{"groupId", "groupName",
>"allArticlesInGroup.articleId", "allArticlesInGroup.articleName"});
>
>Iterator iter = broker.getReportQueryIteratorByQuery(q);
>while (iter.hasNext())
>{
>list.add(iter.next());
>}
>
>// 7 Articles, 2 Books, 3 Cds
>assertEquals("check size", list.size(), 7);
> }
>
>SELECT DISTINCT
>A0.Kategorie_Nr,A0.KategorieName,A1.Artikel_Nr,A1.Artikelname FROM
>Kategorien A0 LEFT OUTER JOIN Artikel A1 ON
>A0.Kategorie_Nr=A1.Kategorie_Nr LEFT OUTER JOIN BOOKS A1E0 ON
>A0.Kategorie_Nr=A1E0.Kategorie_Nr LEFT OUTER JOIN CDS A1E1 ON
>A0.Kategorie_Nr=A1E1.Kategorie_Nr WHERE A0.Kategorie_Nr = '5'
>
>hth
>jakob
>
>Mark Rowell wrote:
>
>
>
>>Hi
>>
>>I was wondering if report queries on extents work where I am selecting out
>>a/some column(s) from a table
>>related to the extent classes. A concrete example may help (!)
>>
>>I have an extent class called Bond with concrete implementations called
>>FixedCouponBond and FRN.
>>There is a 1 to n relationship a single Bond and the priceDetails class
>>(which is concrete). In my
>>repository_user.xml file they mappings are setup as follows (I only show
>>themapping for the FixedCouponBond class
>>as it is identical for the FRN class)
>>
>> >class="com.credittrade.instruments.securities.BBGBondModel"
>>
>>table="Bonds"
>> >
>> >name="id"
>>column="ID"
>>jdbc-type="INTEGER"
>>primarykey="true"
>>autoincrement="true"
>> />
>> etc
>> >name="priceDetails"
>>element-class-ref="com.credittrade.market.PriceDetail"
>>auto-retrieve="true"
>>auto-update="false"
>>auto-delete="false"
>>proxy="true"
>> >
>>
>>
>>etc
>>
>>
>>priceDetail is mapped as follows:
>>
>> > class="com.credittrade.mark
RE: Report queries on extents
Hi Jakob
Thanks for that but my generated SQL does not qualify the columns I was
selecting and hence
I get a non unique name for the ID column reported by SQL Server. One
difference between the example you give and
my example is that my criteria filters on a couple of values in a collection
attribute of the class I am querying.
E.g. to extend the example you give:
public void testReportPathExpressionForExtents()
{
ArrayList list = new java.util.ArrayList();
Criteria crit = new Criteria();
crit.addEqualTo("groupId", new Integer(5));
crit.addEqualTo("allArticlesInGroup.articleName", "some name");
ReportQueryByCriteria q =
QueryFactory.newReportQuery(ProductGroup.class, crit, true);
q.setColumns(new String[]{"groupId", "groupName",
"allArticlesInGroup.articleId", "allArticlesInGroup.articleName"});
Iterator iter = broker.getReportQueryIteratorByQuery(q);
while (iter.hasNext())
Additionally, is ProductGroup an extent? The class I query is the top level
of an extent.
I will make a change to the test you give so it looks like my query and then
see what results I get.
I will also send you the generated SQL.
Regards & thanks
Mark
-Original Message-
From: Jakob Braeuchi [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 19, 2003 4:48 PM
To: OJB Users List
Subject: Re: Report queries on extents
hi mark,
yes, report queries are extent aware. the method below is taken from the
testcase QueryTest and it produces the query shown further down.
public void testReportPathExpressionForExtents()
{
ArrayList list = new java.util.ArrayList();
Criteria crit = new Criteria();
crit.addEqualTo("groupId", new Integer(5));
ReportQueryByCriteria q =
QueryFactory.newReportQuery(ProductGroup.class, crit, true);
q.setColumns(new String[]{"groupId", "groupName",
"allArticlesInGroup.articleId", "allArticlesInGroup.articleName"});
Iterator iter = broker.getReportQueryIteratorByQuery(q);
while (iter.hasNext())
{
list.add(iter.next());
}
// 7 Articles, 2 Books, 3 Cds
assertEquals("check size", list.size(), 7);
}
SELECT DISTINCT
A0.Kategorie_Nr,A0.KategorieName,A1.Artikel_Nr,A1.Artikelname FROM
Kategorien A0 LEFT OUTER JOIN Artikel A1 ON
A0.Kategorie_Nr=A1.Kategorie_Nr LEFT OUTER JOIN BOOKS A1E0 ON
A0.Kategorie_Nr=A1E0.Kategorie_Nr LEFT OUTER JOIN CDS A1E1 ON
A0.Kategorie_Nr=A1E1.Kategorie_Nr WHERE A0.Kategorie_Nr = '5'
hth
jakob
Mark Rowell wrote:
>Hi
>
>I was wondering if report queries on extents work where I am selecting out
>a/some column(s) from a table
>related to the extent classes. A concrete example may help (!)
>
>I have an extent class called Bond with concrete implementations called
>FixedCouponBond and FRN.
>There is a 1 to n relationship a single Bond and the priceDetails class
>(which is concrete). In my
>repository_user.xml file they mappings are setup as follows (I only show
>themapping for the FixedCouponBond class
>as it is identical for the FRN class)
>
>class="com.credittrade.instruments.securities.BBGBondModel"
>
> table="Bonds"
> >
> name="id"
> column="ID"
> jdbc-type="INTEGER"
> primarykey="true"
> autoincrement="true"
> />
>etc
> name="priceDetails"
> element-class-ref="com.credittrade.market.PriceDetail"
> auto-retrieve="true"
> auto-update="false"
> auto-delete="false"
> proxy="true"
> >
>
>
> etc
>
>
>priceDetail is mapped as follows:
>
>class="com.credittrade.market.PriceDetail"
>table="PriceDetails">
>name="id"
>column="ID"
>jdbc-type="INTEGER"
>primarykey="true"
>autoincrement="true"
>/>
>name="instrumentID"
>column="InstrumentID"
>jdbc-type="INTEGER"
>/>
>name="priceValueType"
>column="typeID"
>etc...
>
>
>
>I run the following report query to retrieve the ISIN field from the
>FixedCouponBond and the
>ID of the associated price details. I do this using the OJB API thus:
>
>// Java snippet
>Criteria criteria = new Criteri
Report queries on extents
Hi
I was wondering if report queries on extents work where I am selecting out
a/some column(s) from a table
related to the extent classes. A concrete example may help (!)
I have an extent class called Bond with concrete implementations called
FixedCouponBond and FRN.
There is a 1 to n relationship a single Bond and the priceDetails class
(which is concrete). In my
repository_user.xml file they mappings are setup as follows (I only show
themapping for the FixedCouponBond class
as it is identical for the FRN class)
etc
etc
priceDetail is mapped as follows:
I run the following report query to retrieve the ISIN field from the
FixedCouponBond and the
ID of the associated price details. I do this using the OJB API thus:
// Java snippet
Criteria criteria = new Criteria();
criteria.addEqualTo("priceDetails.PriceSource", ps.getLabel());
criteria.addEqualTo("priceDetails.TypeID",
PriceValueType.price.toString());
criteria.addEqualTo("priceDetails.PriceTypeID",
PriceType.market.toString());
criteria.addIn("priceDetails.QuoteTypeID", Arrays.asList( new
String[]{
QuoteType.bid.toString(),
QuoteType.offer.toString(),
QuoteType.high.toString(),
QuoteType.low.toString()}));
criteria.addIn("ISIN", isins);
Iterator iter = broker.getReportQueryIteratorByQuery(
QueryFactory.newReportQuery(
Bond.class,
new String[]{"ISIN", "priceDetails.ID",
"priceDetails.QuoteTypeID"},
criteria,
false));
Note in the method call to newReportQuery I ask for the ISIN field from the
Bond class (no qualifier as it is the
class in the query), and the ID and QuoteTypeID columns from the related
priceDetails instances.
The problem I get is that the generated SQL strips out the identifiers and
because I have an ID column on my
Bond tables I get a SQL error complaining that ID is not a unique column
name.
I do this sort of report query elsewhere, on concrete classes directly and
it works -- hence I assume it is a problem with
the SQL generator (?) for extents.
I can get round it by specifying A1 as the qualifier for the ID and
QuoteTypeID columns (as this, I noticed, is the
table alias used by the SQL generator for the PriceDetails table.
So, the questions I have are:
(a) is this a bug, or
(b) am Idoing something wrong...
Regards,
Mark Rowel
Mark Rowell
CreditTrade
T: +44 (020) 7400 5078
M: mailto:[EMAIL PROTECTED]
CreditTrade Limited is regulated by the FSA. (c) 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 CreditTrades 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.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: StatementManager and field conversions of primary key values
Er, I definitely attached the files to the original email to the list so I assume thatthe mail list software filters attachments out when it sends mails to everyone the list? Mark -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 11:22 AM To: '[EMAIL PROTECTED]' Subject: StatementManager and field conversions of primary key values Hi I recently upgraded (today!) from version 0.9.6 to 0.9.9 and I forgot that I patched StatementManager to use field converters for primary key values. I have repatched it for version 0.9.9 and hopefully someone more familiar with the codebase can take a look at the attached patched version for correctness (and add it to the CVS repository). Specifically, I modified the bindSelect and bindDelete methods. If anyone is interested I also have attached an LRUCache implementation. Package is for my local code but feel free to change it and add it to the OJB tree if it is OK. Regards, Mark Rowell ---- Mark Rowell CreditTrade T: +44 (020) 7400 5078 M: mailto:[EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) 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 CreditTrades 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. CreditTrade Limited is regulated by the FSA. (c) 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 CreditTrades 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
StatementManager and field conversions of primary key values
Hi I recently upgraded (today!) from version 0.9.6 to 0.9.9 and I forgot that I patched StatementManager to use field converters for primary key values. I have repatched it for version 0.9.9 and hopefully someone more familiar with the codebase can take a look at the attached patched version for correctness (and add it to the CVS repository). Specifically, I modified the bindSelect and bindDelete methods. If anyone is interested I also have attached an LRUCache implementation. Package is for my local code but feel free to change it and add it to the OJB tree if it is OK. Regards, Mark Rowell Mark Rowell CreditTrade T: +44 (020) 7400 5078 M: mailto:[EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) 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 CreditTrades 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
