Hi, I wasn't quite finished with my previous mail (just a little to quick with my fingers..)
So let me try again: 1. Criteria The criteria for choosing one tool before the other are usability, stability, performance and features (which also includes supporting standards). For our purposes performance is very important. But However, I believe that usability is just as important because it can reduce the time of development and thus saves money. 2. Alternatives As an alternative we have discussed hibernate. It seems to be very mature, easy to learn, well featured and fast(?).But since we have already invested quite a lot of time in using OJB we don't really want to switch (we don't have enough resources to check out everything in detail). Another alternative is to choose a commercial product which could offer extended support (you don't end up in some dead end, wasting too much time by trying to figure out how to do something, you just call the hotline...). But we have read some reports (java-magazine) about those alternatives and they weren't exactly very convincing. Plus we have had some experiences with commercial support in other components that we use, which were more than just disappointing. 3. Documentation The documentation is quite well. Yet still, I have had problems getting started with certain features (like joins). That might be my problem (reading to superficially, lacking certain basics) but it could have gone faster with more examples. Sometimes it takes a while to figure out whether something is not working becuase it just doesn't with OJB or because I messed up. So it is interesting to find out other people's experiences. bye Michael -----Ursprungliche Nachricht----- Von: Michael Ochtrop [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 2. Oktober 2002 09:43 An: OJB Users List Betreff: RE: Real Project with OJB 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
