Hi, thanks for your reports on your current projects. We have started to use OJB in our project as well, but then had certain doubts which I tried to explain in my proveious email.
The criteria for choosing one tool before the other are usability, As an alternative to OJB we discussed hibernate or other commercial tools. We -----Ursprungliche Nachricht----- Von: Thomas Mahler [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 1. Oktober 2002 20:30 An: OJB Users List Betreff: Re: Real Project with OJB Hi Michael, Michael Ochtrop wrote: > Hi, > > I would like to know, if anybody on this list has already > accomplished a real project with OJB. YES! We are running several Struts/OJB based applications for our customers. We using an architecture very close to the beer4all struts/ojb demo by Chuck Cavaness. There have been no performance or stabilitity issues so far. We are running our app under Tomcat and WebSphere. I hope we will have a WebLogic showcase soon. There have been some problems: - It is difficult to use OJB with legacy databases that violate 2nd normal form as OJB relies on primary keys. - We could not use OJB queries in some cases and had to use hand coded SQL with QueryBySql. > My company has (almost) > decided to use OJB in one of our current projects (a webbased > catalogue and online-shop with about 20000 products where each > product consists of 5-20 properties). > What alternatives are you discussing? what are the criteria to choose one tools before the other? > Now there are some aspects about OJB which I consider to be > rather difficult or which I can't really judge yet. So I would > like to hear if somebody has made some _real_ experiences > (other then just "checking out OJB") with the following questions: > > - Is OJB stable enough to handle real projects? > (There have been various bug reports on the list, e.g. > concerning joins which I consider essential) > In our projects we did not find any OJB bugs yet. (Of course there are bug reports on the list. There are 3.000 - 5.000 downloads per month. With such a large user base we will always find bugs in our growing codebase. Being open source is a big help to allow users to detect bugs. If you are using an obfuscated closed source tool debugging may become hard/impossible.) > - How much time does the lack of profound documentation cost? > (If you get stuck, sometimes the manual really doesn't go very > far. That could cost time and money). Mhh, being the writer of most of the documentation I feel that OJB documentation is quite extensive, accurate and covers a lot of in depth things. Did you ever have a look at the TopLink manual? reading their manual I always feel: "sometimes the manual really doesn't go very far. That could cost time and money" ;-) Of course documentation can always be improved. What exactly is missing? > > - How often do you need a "workaround" due to lacking features? > (E.g. lacking capability of mapping one class on multiple tables or > not fully implemented OQL). We had to use some workarounds as mentionend above. But they where due to bad legacy data models not due to OJB. > > - Has the performance proven acceptable in a real environment even > though it is slower than native jdbc? > No user complaints so far. If you are writing GUI based applications overall performance won't suffer. For batch mode apps it may be more adequate to use native JDBC. But this can slo coexist with normal OJB code. cheers, Thomas > > Thanks for any feedback > > Michael > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
