RE: Official implementation request.

2004-08-20 Thread Mahler Thomas
Hi Nathan, If you have a compound primary key of say 7 columns and 6 of them are (or can be) blank or null then only the seventh column can be used as a real primary key. So from an OJB point of view you could just solve the issue by declaring on the seventh column as primary key in the

Oracle and case-insensitive search

2004-08-20 Thread Frank Renaers
Hi, In Oracle a search on a string (Criteria.addLike) seems to be Case Sensitive. How do you guys solve this problem. In MsSql and MySql a Criteria.addLike is not case sensitive ! Thanks, Frank Renaers

Re: Oracle and case-insensitive search

2004-08-20 Thread Danilo Tommasina
Hi, you can just do something like this... Criteria c = new Criteria(); c.addLike( upper(yourField), yourString.toUpperCase() ); cheers Danilo Hi, In Oracle a search on a string (Criteria.addLike) seems to be Case Sensitive. How do you guys solve this problem. In MsSql and MySql a

Re: Official implementation request.

2004-08-20 Thread Clóvis Wichoski
Hi, When we need this, I never use database NULL value for PK, instead I use a String initiated with 'NULL' then the Querys can change from: SELECT * FROM table1 WHERE field1 IS NULL AND field2 = '0001' to: SELECT * FROM table1WHERE field1 = 'NULL' AND field2 = '0001' This idea work on any

Re: pbapi + select from multiple tables

2004-08-20 Thread Clóvis Wichoski
Hi, in your BAR class you don't declare a collection for FOO, and a collection for BAR childs? Joose Vettenranta wrote: I have like FOO and BAR classes and it's 1:n connection.. There can be lot's of FOO pointing to same BAR id and BAR has parent id which points to BAR itself now I would like to

OJB+JNDI Datasource clarification

2004-08-20 Thread abo
hi, I have read some postings about OJB's datasource handling and I'm confused now. It's said, that you have to a.) put username/password both in the datasource.xml and repository_database.xml or b.) let username/password blank and give it to the broker (with pbkey) at runtime. why is that? if

OJB+JNDI Datasource clarification

2004-08-20 Thread Andreas Bohnert
hi, I have read some postings about OJB's datasource handling and I'm confused now. It's said, that you have to a.) put username/password both in the datasource.xml and repository_database.xml or b.) let username/password blank and give it to the broker (with pbkey) at runtime. why is that? if

Re: Official implementation request.

2004-08-20 Thread Robert r. Sanders
I'd tend to force an artificial primary key (as an extra field); but I suppose the customization options offered by OJB would allow you to write your own call-back to enable the kind of functionality your talking about. Clóvis Wichoski wrote: Hi, When we need this, I never use database NULL value

Re: OJB+JNDI Datasource clarification

2004-08-20 Thread Andreas Bohnert
thanks for your quick response, armin! I see, the pwd/user settings in repository_user.xml are optional! ok, that's good, so I have only one problem left. maybe you can give me a hand with this: I have just one ear file with my ejb's, war's, jar's and ojb.sar inside, and I have my datasource.xml

Massive concurrency problems under high server load

2004-08-20 Thread Gerhard Grosse
Hi, We have developed a servlet application using a slightly modified version of OJB 1.0RC5 using the ODMG API. The application has been tested with Unit Tests, comprehensive manual funcional tests, and (mainly single-threaded) performance tests and everything seemed to work well. As last step

out of the box SQL - .java tool?

2004-08-20 Thread Jason Pyeron
Almost a year ago, we had started an in-house tool development like such, we figured since OJB has matured so much that there would be a mature tool to do such, preferably from ant. http://db.apache.org/ojb/docu/howtos/howto-build-mappings.html says that the ReverseDB tool is not up to date :(

Re: Massive concurrency problems under high server load

2004-08-20 Thread Armin Waibel
Hi Gerhard, this sounds alarming :-( Gerhard Grosse wrote: So my main questions are: - Have substantial things changed between RC5 and 1.0 that might have improved OJB's behavior under high concurrent load. we made serveral improvements between rc5 and 1.0. The performance improvement of the

Re: Massive concurrency problems under high server load

2004-08-20 Thread Armin Waibel
I run some massive multithreaded tests against the 1.0_RELEASE branch in CVS (against hsql in-memory mode, single CPU) without failures (with tweaked OJB settings). In this test each thread work on separate objects, maybe the problems occur only when different threads work on the same objects.