Discussions

News: Apache Object/Relational Bridge 1.0 Released

  1. I'm very happy to announce the final 1.0 release of Apache OJB. After a long series of release candidates we finally got enough confidence in our software to call it "ready for prime time".

    As you can see by our ever growing list of junit tests we pay attention to quality assurance. So the long delay of the 1.0 version was not caused by "laziness" but rather by our intention to deliver a piece of top quality software.

    I want to say thanks to all committers and contributors: You all helped to get OJB production ready!

    I also want to thank all users for their patience and I hope you all will be pleased by this 1.0 release!

    The release is available at http://db.apache.org/ojb/

    Threaded Messages (32)

  2. How does this compare with Hibernate? It sounds similar to it.
  3. Comparision website[ Go to top ]

    To answer my own question

    http://c2.com/cgi/wiki?ObjectRelationalToolComparison
  4. Sifting Through the Chaff[ Go to top ]

    How does this compare with Hibernate? It sounds similar to it.
    I spent sometime looking at the comparison Wiki that was presented right after this post and I will not attempt to give my (learned, educated, off-base, egotistic, pick one) opinion of the two frameworks.

    In general, I feel that the road will be long and fraught with peril for the OJB project because it does not appear to do much better than Hibernate does. I read through the 37 points of functionality in O/R tools and of those 37, Hibernate only does not support about three of them. So, in other words, Hibernate is a feature rich, well supported product with an active community and a number of installs. It's good at what it does and it has a lot of proponents.

    On the other hand, you have the OJB project which does about what Hibernate does. The major differences I see are that OJB has a JDO API right now which Hibernate does not (and why would it, I've always seen Hibernate as a JDO killer) and Hibernate is WIP on the ODMG API which OJB has. One clear distingusiher between Hibernate and OJB is the fact that OJB maps a class to multiple tables and in general OJB handles mapping to multiple database. Still, that's not enough for me to switch.

    So in the end, I don't see anything wrong with OJB, I just think it (and JDO and a bunch of other O/R frameworks) are too late.
  5. OJB Things Hibernate Lacks[ Go to top ]

    Hibernate and OJB solve the same general class of problems, they'll be similar =) Both have some things the other lacks though. Imagine that.

    Some (not all) things OJB has which Hibernate lacks (to my knowledge as a sometimes Hibernate user, more often OJB user and developer):

    Support for transactions which are optimistic from database perspective but have the standard isolation levels available within the application (ie, repeatable-read within the context of everything participating in the OJB cache, but optimistic on db). This is a nice spot for a lot of apps, completely useless in others =)

    You can mix and match object graphs persisted to different data sources.

    You can modify the mapping at runtime (Hibernate may have added this recently), add mappings, change isolation levels, even change the datasources.

    We can also map some really bizarre edge cases a little bit easier, but this is an opinion, and doing those things requires pretty solid knowledge of the platform no matter what, so...

    A really useful one is simply that proxies can be de-referenced anytime. In Hibernate there is a problem that your object graph ends at the proxy. This is reasonable behavior, and is hard to get around in Hibernate's connection oriented model. You get odd things like per-request Session instances which are opened and closed in a servlet filter. Outside of a transaction OJb will simply borrow another broker from the pool, fetch what you need, and return the broker. The instances are non-transactional, but this is what you want or you would have fetched them in the transaction =)

    Finally, the biggest difference is something that Stefano Mazzochi said about the ASF in general -- we don't usually make standards, we implement them. We have a (weak) JDO implementation now (don't get me started on JDO please, I don't feel nearly as strongly as Gavin, but I have serious issues with the 1.0.1 spec -- 2.0 solves the single biggest for me though) and we are working on a robust 2.0 impl since the spec is now available. We support ODMG. We will support EJB3 when it is actually standardized.


    A lot of these are things that classically Gavin King has said don't belong in O/R mapping (which category, until he started working at JBoss, he included "standards" in ;-) and if you want them you should redesign your app so you don't want them anymore. Frankly, enough people have wanted them that we have implemented them.

    Hibernate does a few nice things that OJB doesn't as well. I think HQL is darned good. It is the best object/relational query language I know of right now (and I really liked O2). One of the OJB guys actually implemented it on OJB a while back, but for (hopefully) obvious reasons we never committed it or made it available.

    It also provides a nicer attach/detach api (ie, an explicit one) whereas we just have an implicit one. Explicit is generally *good*.

    Hibernate is very good. It is not the be-all end-all for o/r mapping though. I have heard Gavin say he thinks it is the best solution for *every* o/r mapping need, but where I frequently agree with him on a lot of things, I believe he is dead wrong there. The field is still quite immature (heck, there will be 4 "standards" for O/R mapping in javax.*.* in 1.5^H^H^H 5.0. Scariest part is that just this week I ran across a better way to do O/R mapping (not the how-you-map part, but the implementation) which I think will outperform ANYTHING I have yet seen. It isn't in OJB, or Hibernate, or TopLink, or Cayenne.

    -Brian
  6. Scariest part is that just this week I ran across a better way to do O/R mapping (not the how-you-map part, but the implementation) which I think will outperform ANYTHING I have yet seen. It isn't in OJB, or Hibernate, or TopLink, or Cayenne. -Brian
    So someone finally had a look at Ward Mullins magic patents? :)

    Seriously, I'd be interested how OJBs locking stuff implements offline pessimistic shared read/write locks without switching the database transaction to Serializable. Are only exclusive locks supported? Do you use a second serializable database transaction to check/update the lock table?

    (I think you not actually misquoted Gavin in some of your statements, but probably misunderstood him, but he can speak for himself...)
  7. Oh, another question: If you randomly fetch data from the database (your statement how OJB proxies work), you also have ad hoc transactions. How do you deal with inconsistency, for example, if the entity that contained the proxy is no longer in the database?
  8. OJB Things Hibernate Lacks[ Go to top ]

    Oh, another question: If you randomly fetch data from the database (your statement how OJB proxies work), you also have ad hoc transactions. How do you deal with inconsistency, for example, if the entity that contained the proxy is no longer in the database?
    It must be almost the same as "optimistic transaction", has nothing in common with transactions, but works.
  9. OJB Things Hibernate Lacks[ Go to top ]

    How?
  10. OJB Things Hibernate Lacks[ Go to top ]

    "Transparent" (It can be wrong, but nobody will see it)
  11. OJB Things Hibernate Lacks[ Go to top ]

    Seriously, I'd be interested how OJBs locking stuff implements offline pessimistic shared read/write locks without switching the database transaction to Serializable. Are only exclusive locks supported? Do you use a second serializable database transaction to check/update the lock table?(I think you not actually misquoted Gavin in some of your statements, but probably misunderstood him, but he can speak for himself...)
    The Lock mechanism is pluggable, so the semantics depends on the actual implementation.
    The default LockMap implementation is an in-mory map. Thus it can only be used if no synchronization across multiple VMs is required.

    There is also c/s version available. It uses a separate servlet that keeps a Map of Locks. This servlet has no database connection. All locks are hold in-memory.
    This solution uses the same concepts as the LockServer of the Objectivity OODBMS.

    There was also a persistent LockMap implementation availabe, but this has been deprecated (it was replaced by the ServetLockmap mentioned above). We didn't find a clean solution do to the additional transaction handling for the LockMap in managed environments.
  12. Nice...[ Go to top ]

    A really useful one is simply that proxies can be de-referenced anytime. In Hibernate there is a problem that your object graph ends at the proxy. This is reasonable behavior, and is hard to get around in Hibernate's connection oriented model. You get odd things like per-request Session instances which are opened and closed in a servlet filter. Outside of a transaction OJb will simply borrow another broker from the pool, fetch what you need, and return the broker. The instances are non-transactional, but this is what you want or you would have fetched them in the transaction =)

    I like that...

    I already implemented it in my program (as a workaround to the problem in hibernate), but I definitely like it -- brings the tool one step closer to "transparent".

    Hibernate is darned good no doubt, but I think there is plenty of room for other implementations to excel. Personally, I'm finding "Hibernate's way" a bit frusterating in a 2-tier swing application (it keeps too strong a hold on objects).
  13. OJB Things Hibernate Lacks[ Go to top ]

    Congrats to the OJB team.

    It will definately grow the acceptance and spreading of OJB if you will conlucrate with the Spring team and get Spring support for OJB. It would be nice and it makes me droll when thinking that I'll actually have a chance to switch a dao layer implemented with hibernate with a dao layer implemented with OJB and get the chance to say 'Hey Gavin ! You might be wrong about that thing ! OJB implements it in a nice way and it actually works. :-)' Until than as I allways said competition means evolution. I'm sure OJB rocks !
  14. OJB Things Hibernate Lacks[ Go to top ]

    First of all, congratulations to the OJB team too, for finally getting the release out! It was just about time :-)

    I appreciate that OJB goes beyond other O/R mapping solutions in that it provides features not covered by them. No matter how useful those are, actually - it's important to compete in terms of features, particularly in such a wide-ranging area like O/R mapping. That's what keeps the field evolving.

    IMO, the biggest deficiency of OJB 1.0 is that it hasn't a clear recommended user API:
    - The JDO 1.0 RI plugin? Not recommended by the OJB guys themselves.
    - ODMG? Well, hardly what you could consider a modern persistence API.
    - OJB's PersistenceBroker? Too low-level, doesn't do object transactions.
    - The only API left is OJB's own OTM, but that's not really advocated either.

    Of course, I appreciate it that the OJB team is working on a JDO 2.0 API. That should finally give OJB users a single recommended API. I believe that the single clear API and query language are major success factors of Hibernate, and OJB should learn from that.

    Regarding Spring integration: We have been pursuing that for quite a while, but we need a specific API to work with. Before the rather recent addition of the OTM, there wasn't any that we could consider for the long term. Now we could provide integration at the OTM level, but this hasn't been done yet.

    It seems that JDO 2.0 will be the preferable choice quite soon: OJB will then work right away with Spring's JDO support. I'd love to hear opinions whether it would still be worth doing a separate integration for the OTM API. What do current OJB users mostly work with, for example?

    BTW, the upcoming Spring 1.1 introduces significant enhancements in the JDO support area, like convenience operations on JdoTemplate, support for Open PersistenceManager in View, and an extended JdoDialect API that's been prepared for JDO 2.0.

    Juergen
  15. OJB Things Hibernate Lacks[ Go to top ]

    I was wondering why you think that ODMG is not a modern persistence API ? Almost all OJB users either use OMDG or the PB Api depending on whether they need transactions, not (to my knowledge) based on the cleanness of the API. IMO both are simple to use and powerful. Btw, the JDO RI is simply not recommended because it is slow in parts. The reason is that providing an OJB backend for the RI that is fast enough, would require changes in the RI (it's not extensible enough). Other than that it works AFAIK.

    You're right, Spring integration is one of the most desirable features for OJB. Do you have any figures as to when Spring 1.1 (incl. the enhancements regarding JDO) will be available ?
  16. OJB Things Hibernate Lacks[ Go to top ]

    I was wondering why you think that ODMG is not a modern persistence API?
    Well, ODMG 3.0 dates back to 1999 and is not evolved anymore. It's basically abandoned. I think it's extremely important for an API to be able to evolve, for example to adapt to new features of the underlying platform. ODMG may still be usable at this point of time, but will it be in a couple of years?
    Almost all OJB users either use OMDG or the PB Api depending on whether they need transactions, not (to my knowledge) based on the cleanness of the API. IMO both are simple to use and powerful.
    I don't doubt that they are useful, by any means. It's just unclear for users which API to choose for the long term. OK, the PB API is appropriate if you don't need object-level transactions. But which of the higher-level ones to choose for the long term - ODMG, JDO 1.0 RI plugin, or OTM?
    Btw, the JDO RI is simply not recommended because it is slow in parts. The reason is that providing an OJB backend for the RI that is fast enough, would require changes in the RI (it's not extensible enough). Other than that it works AFAIK.
    It's simply not a good strategy for the long term to base this on the JDO RI. I'm really looking forward to a proper JDO API implementation for OJB that can fully leverage the backend. IMO it's very important to expose the backend's full power in an appropriate API.
    You're right, Spring integration is one of the most desirable features for OJB. Do you have any figures as to when Spring 1.1 (incl. the enhancements regarding JDO) will be available ?
    Spring 1.1 RC1 is currently scheduled for July 11th, with 1.1 final by early August. RC1 is basically ready in CVS, including the enhanced JDO support.

    As much as I'd like to help advance OJB integration, it's unclear for me on which of OJB's APIs to focus. It might be appropriate to cover the PB API in any case, but it doesn't make much sense to cover 3 high-level APIs. We need to focus our efforts here.

    Given that OJB's JDO API is usable through Spring's JDO support anyway, I wonder which of the other APIs are worth building direct support for them. OTM doesn't really seem to be intended for direct usage, and I'm not too keen on ODMG. From my point of view, that leaves the PB API...

    Juergen
  17. OJB Things Hibernate Lacks[ Go to top ]

    I don't doubt that they are useful, by any means. It's just unclear for users which API to choose for the long term. OK, the PB API is appropriate if you don't need object-level transactions. But which of the higher-level ones to choose for the long term - ODMG, JDO 1.0 RI plugin, or OTM?
    We're currently advoacting PB and ODMG for use: PB is IMO simpler but lacks transactions whereas ODMG is a standard, supports transactions and OQL as a decent SQL replacement so to speak.
    It's simply not a good strategy for the long term to base this on the JDO RI. I'm really looking forward to a proper JDO API implementation for OJB that can fully leverage the backend. IMO it's very important to expose the backend's full power in an appropriate API.
    I fully agree with you here. The current JDO plugin is basically a proof-of-concept (that might even be usable in production environments but is not really fast). We'll see about the enhancements/changes in the upcoming JDO2, as there is certainly a lot of interest in a proper JDO implementation for OJB.
    Spring 1.1 RC1 is currently scheduled for July 11th, with 1.1 final by early August. RC1 is basically ready in CVS, including the enhanced JDO support. As much as I'd like to help advance OJB integration, it's unclear for me on which of OJB's APIs to focus. It might be appropriate to cover the PB API in any case, but it doesn't make much sense to cover 3 high-level APIs. We need to focus our efforts here. Given that OJB's JDO API is usable through Spring's JDO support anyway, I wonder which of the other APIs are worth building direct support for them. OTM doesn't really seem to be intended for direct usage, and I'm not too keen on ODMG. From my point of view, that leaves the PB API.
    My knowledge of Spring is limited, so correct me if I'm wrong here, but the transactions handling in Spring is automatic (hidden from the user), which would make OTM the prime candidate esp. for its transaction handling in combination with the PB Query-Api (or OQL if the user prefers to - it can be used with the PB/OTM Api with no problems). If you're interested, we could discuss this off the forum, as I'd really like to see full OJB support in Spring 1.1 and would provide any help that is needed.
  18. OJB Things Hibernate Lacks[ Go to top ]

    We're currently advoacting PB and ODMG for use: PB is IMO simpler but lacks transactions whereas ODMG is a standard, supports transactions and OQL as a decent SQL replacement so to speak.
    I assume that the ODMG recommendation will be superseded by JDO 2.0?

    On the occasion, I noticed that OJB uses a lot of singletons for initialization, which does not allow Spring's configuration model to apply its full power (everything is instance-based there). JDO's PersistenceManagerFactory configuration is also instance-based: I wonder how that matches with OJB's current initialization style?
    My knowledge of Spring is limited, so correct me if I'm wrong here, but the transactions handling in Spring is automatic (hidden from the user), which would make OTM the prime candidate esp. for its transaction handling in combination with the PB Query-Api (or OQL if the user prefers to - it can be used with the PB/OTM Api with no problems).
    Spring's transaction management should work nicely with the PB API too. Basically, Spring has a PlatformTransactionManager SPI that needs to be implemented for each transaction strategy. We could provide 2 implementations here: one for PB transactions, one for OTM transactions.

    We'd then need to provide template classes for data access operations that automatically participate in surrounding transactions. We'd need one for the PB API and a separate one for the OTM API. As it seems, both could share the same exception translation (to Spring's DataAccessException hierarchy), as the OTM API simply passes PB exceptions through.

    BTW, neither the online javadocs nor the ones in the doc download cover the OTM API. I had to look at the sources to check interface details... The OTM API doesn't seem to be advocated for direct usage to me. Do you really expect people to work at that API level? If not, it doesn't make much sense to provide Spring integration for it.
    If you're interested, we could discuss this off the forum, as I'd really like to see full OJB support in Spring 1.1 and would provide any help that is needed.
    Sure. Send me an email to my SourceForge address (my username is "jhoeller").

    Juergen
  19. OJB Things Hibernate Lacks[ Go to top ]

    IMO, the biggest deficiency of OJB 1.0 is that it hasn't a clear recommended user API:
    - The JDO 1.0 RI plugin? Not recommended by the OJB guys themselves.
    - ODMG? Well, hardly what you could consider a modern persistence API.
    - OJB's PersistenceBroker? Too low-level, doesn't do object transactions.
    - The only API left is OJB's own OTM, but that's not really advocated either.
    IMO it's a big plus to provide users with different API that serve different
    purposes. We provide some recommendations regarding API choice on our FAQ page.

    - JDO RI plugin is not ready for production, but can be used for any other purposes (training, research, etc.)
    - ODMG is usefull for migrating existing ODMG apps,
      also used by users that need
    - PB is good for implementing DAO patterns based apps. (90% of all business apps that I know do not use any object level transaction management!)
    - OTM is our proprietary API for providing object level transactions
    Of course, I appreciate it that the OJB team is working on a JDO 2.0 API. That should finally give OJB users a single recommended API.
    I think we will continue to provide multiple APIs. I don't believe in things like "a single recommended API".
    Users have different problems, that need to be adressed by different approaches.
    It seems that JDO 2.0 will be the preferable choice quite soon: OJB will then work right away with Spring's JDO support. I'd love to hear opinions whether it would still be worth doing a separate integration for the OTM API. What do current OJB users mostly work with, for example?BTW, the upcoming Spring 1.1 introduces significant enhancements in the JDO support area, like convenience operations on JdoTemplate, support for Open PersistenceManager in View, and an extended JdoDialect API that's been prepared for JDO 2.0.Juergen
    I agree that JDO2.0 will be a very important step for the o/r market in general and OJB in particular!
    After having a final 1.0 release it will be much easier for us to concentrate on JDO2.0.
    And we will worl hard to come up with a good implementation!
  20. OJB Things Hibernate Lacks[ Go to top ]

    IMO it's a big plus to provide users with different API that serve different purposes. We provide some recommendations regarding API choice on our FAQ page.
    Different API levels that serve different purposes are fine, agreed. My concern is that it is important for new users to concentrate on a recommended API, or maybe one of two recommended APIs. The other API are fine, but should be marked as intended for advanced users and system integrators (or the like).

    In OJB's concrete case, the PB API seems to be one the two recommended APIs. You should further clarify your long-term recommendation for object-level transactions, though: This seems to be the JDO API, with the OMDG API as intermediate solution? At least this is what the FAQ seems to indicate.
    PB is good for implementing DAO patterns based apps. (90% of all business apps that I know do not use any object level transaction management!)
    Good point regarding many apps not using object-level transactions! Particularly many web applications don't, as they explicitly store reattached objects. However, they can benefit from efficient dirtiness detection on reattachment, particularly for nested collections. Does the PB API provide this?
    I think we will continue to provide multiple APIs. I don't believe in things like "a single recommended API".Users have different problems, that need to be adressed by different approaches.
    I hope I was able to clarify what I meant with "recommended API". As I said above, multiple APIs are fine. I do believe that a clear recommended API (or maybe two for clearly distinct usage styles) is very important for new users, though. Same goes for query style.
    After having a final 1.0 release it will be much easier for us to concentrate on JDO2.0.And we will worl hard to come up with a good implementation!
    That's good to hear - I'm really looking forward to it!

    Juergen
  21. "conlucrate" ?[ Go to top ]

    In what dictionary did you find this word? What do you intend it to mean? I can only surmise that it might mean a pooling of financial resources, although I do not think "lucre" in the sense of money has a long, let alone a Latin, pedigree.

    Yours for pervasive drollness,
    FW
    .
  22. Does OJB supports transparent 1-n unidirectional associations?
    Last time when I looked in order to have unidirectional 1-n you need to have FK field in child class. As I know in Hibernate there is a problem in 1-n undirectional associations and they are not willing to fix because of other complications :).

    It's a really important funcionality when mapping object models to DBMS. Because usually when I have class A which has collection of classes B from other package I
    do not want to have that B knows about A.

    Giedrius
  23. 1:n etc[ Go to top ]

    Yes. you need to mentionthe fk in the mapping, but it need not be in the java class. In the field descriptor just set "access='anonymous'" on the field and it will be tracked by OJB internally for you =)
  24. 1:n etc[ Go to top ]

    So, it's the same as in Hibernate.
  25. In which version?[ Go to top ]

    In which version of Hibernate 3.x ? Definetly it's not in 2.1.x.
  26. the one thing about Hibernate[ Go to top ]

    I have looked at several frameworks, each time including Hibernate, and each time I rejected it because it requires me to make changes to the interface of my classes. I'm a strong believer of the behaviour that persistency is something that a class should just "do", based on the way it has stored its data internally. Hibernate forces me to create set/get for my private data fields that are unpublished. That I refuse.
  27. Hibernate doesn't need to use getters and setters since it can acceess data fields directly. Look at chapter 5.1.9 of Hibernate documentation.

    The documentation states:

    "The access attribute lets you control how Hibernate will access the property at runtime. By default, Hibernate will call the property get/set pair. If you specify access="field", Hibernate will bypass the get/set pair and access the field directly, using reflection. You may specify your own strategy for property access by naming a class that implements the interface net.sf.hibernate.property.PropertyAccessor."
  28. Sifting Through the Chaff[ Go to top ]

    So in the end, I don't see anything wrong with OJB, I just think it (and JDO and a bunch of other O/R frameworks) are too late.
    Too late? OJB was launched in November 2000! It's hosted at Apache since 2001.
    We have a large and growing base of faithful users.
    We have a production quality software with a rock solid architecture.
    So I really can't see why we should be too late...
  29. Map support[ Go to top ]

    As I understand OJB does not support java.util.Map for many-to-many relationships.
  30. Congratulations to the OJB team. Reaching the 1.0 release milestone should attract some attention and possibly attract some new users. I saw you have some new tutorials available online - got to take the time now to try them out. One thing that would help with the learning curve for new users would be a book dedicated to OJB. Any plans for a Professional OJB Development or an OJB in Action?

    Thomas
  31. I am a OJB user since mid last year. I switched from Hibernate. Currently, I have OJB in production environments and OJB is doing an excelent work there. OJB is pretty stable.

    As witness of all the efforts the OJB team did during the last year to reach the 1.0 release. I saw how they carefully fixed a lot of bugs hunting for the excelence in this 1.0 version.

    The OJB team is small, full of smart people that know what they are doing. All the time looking for enhancements and improvements of OJB. I wish to see soon more OJB versions with nice new features and improvements.

    Many thanks for this release! and at laeast but no less important:

    Congratulations to all people involved in the OJB development effort!
  32. What about JDO support?[ Go to top ]

    Ok. So you've finally released it... Congratulations!

    Any idea (anybody) on when will a version with a JDO 2.0 compatible API (no plugin, from what I'v heard on the official site) be available?

    Regards,
    Freddy.
  33. Congratulations to OJB team!

    We've choosen OJB over Hibernate primarily for JDO support but use OJB's Persistence Broker API to do the work. We are doing quite unusual things with our data objects and found that OJB is very customizable. Most of the sources are well written, and discovered bugs were quickly fixed. Our production system have been pretty stable on version 1.0RC5+ for 5 months.

    Thank you guys!