Forgot your password?
typodupeerror
Java Books Media Programming Book Reviews

Java Data Objects 165

Posted by timothy
from the concentrate-on-the-beans dept.
Reader java1dev submits the following brief review of O'Reilly's Java Data Objects, which he says provides excellent coverage of JDO. His capsule description of the book: "First, a high-level overview, followed by an in-depth coverage of the core features, and concluding by describing the more complex concepts in detail. Running throughout the book is an excellent intuitive example application that illustrates the features being covered." Read on for more of his review.
Java Data Objects
author David Jordan & Craig Russell
pages 356
publisher O'Reilly & Associates
rating 9
reviewer java1dev
ISBN 0596002769
summary Excellent, example-filled introduction and practical guide to Java Data Objects.

Craig Russell, at Sun Microsystems, is the specification lead for JDO and David Jordan, at Object Identity, has been an active member of the JDO expert group since its inception.

Java Data Objects provides a thorough coverage of JDO and explains how it can be used in various architectures. The reader is expected to be familiar with Java but needs only a limited knowledge of databases. In brief, Java Data Objects (JDO) insulates you from needing to know a lot about databases. JDO permits you to develop applications using your preferred Java object-oriented model, without you having to write code to translate between Java objects and how the data is stored in the database--JDO takes care of all of that for you.

The first three chapters provide a high level overview of JDO by walking through a small application, exploring each of its interfaces at a high level, and introducing the architectures it might be used in. Even if you have been away from code for a while you will be able to follow most of the code example. You can stop here if you just want to understand what JDO is all about and where it can be used. These are recommended reading for a manager.

Chapters 4 through 9 are required reading if you want to start developing JDO applications. They really get you into JDO, so you can understand it and start using it. The first three of these cover how to define persistent classes and fields, how they can be mapped to various databases (done for you) and the class enhancement process (which makes a lot of JDO transparent to you). The next three (chapter 7 through 9) bring home the power of JDO. These cover how to connect with a database, establish a transaction context and create, read, query, update and delete database objects. The material is made concrete by illustrating it with a detailed and intuitive example application. This example is carried throughout the book with sections of it explained as the concepts are covered.

Each remaining chapter covers a different JDO concept or feature (including optional features) that were introduced earlier but not covered in detail to keep the earlier chapters more understandable. These remaining topics are identity, lifecycle states & transitions, field management, cache management, nontransactional access and optimistic transactions. You can read these chapters as you feel the need for a more in-depth understanding of these concepts.

The last two chapters explain how to use JDO in an application-server environment and an Enterprise Java Beans environment. These two chapters assume you are already familiar with these environments, but I think a lot of it is understandable even if you are not.

There are five appendices with everything from the lifecycle state transitions to the collected source code for many of the classes used in the example application.


You can purchase Java Data Objects from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

This discussion has been archived. No new comments can be posted.

Java Data Objects

Comments Filter:
  • suggestion (Score:5, Insightful)

    by newsdee (629448) on Tuesday May 06, 2003 @12:03PM (#5891770) Homepage Journal
    Would it be possible to add the suggested retail price (MSRP) of a book in a review?
    Yes, it can be found by searching the web, but it's just extra comfort brought by a small database tweak. :-)

  • by kisrael (134664) on Tuesday May 06, 2003 @12:04PM (#5891782) Homepage
    I've heard that JDO is much better, tighter solution to O/R mapping than EJB Entity Beans, that the latter are designed to be SO flexible that you can use them as a wrapper to your legacy mainframes, but the former is a lot closer to the problem most Java folks need to solve. Anyone know if that's a reasonable viewpoint?

    (For the record, at this point I hate, hate EJBs. I think they're speficially responsible for the failure of multitudinous Java server projects, way to much overhead for 95% of all things you'd want to do in Java on the server, and the bad apple that risks spoiling the whole J2EE barrel.)
    • by pmcevoy (10501) on Tuesday May 06, 2003 @12:15PM (#5891908) Homepage
      I have to agree - its got to the point where I question _anyones_ use of EJBs - that last 5% is far too specialized.

      I've started using Castor which aint quite JDO, but very close and a damn site easier than EJBs...
    • by ideonode (163753) on Tuesday May 06, 2003 @12:17PM (#5891925)
      There's an interesting thread [theserverside.com] over at TheServerSide which discusses JDO vs. Entity beans.

    • by digerata (516939) * on Tuesday May 06, 2003 @12:17PM (#5891926) Homepage
      You are right on. EJBs are very easy to miuse and generally are cumbersome to wrap around smaller projects. It looks like JDO might be a nice alternative to rolling your own persistance layer. I'd like to see a comparision between JDO and other products like Toplink.
      • by rutledjw (447990) on Tuesday May 06, 2003 @12:28PM (#5892049) Homepage
        EJBs are very easy to miuse -

        This is what I've seen being the biggest issue with Entity EJBs. Where I work, they've taken a bunch of old mainframe coders (who weren't very good there as far as I can tell), sent them to _a_ Java class, then to _an_ IDE class and turned them loose.

        They all heard EJB and went wild. So the result is a bunch of junior programmers with little understanding of Java, much less J2EE writing "Enterprise Applications". Needless to say we've had some problems - performance and maintainability come to mind...

        "Baby with a gun" isn't extreme enough to really describe the current situation...

      • by olip (203119) on Tuesday May 06, 2003 @01:40PM (#5892922)
        Comparing is not the best way to go.
        From what I've heard, Toplink is due to implement somehow the JDO specs in a few months.
        Seems they are trying to change the spec (making the "code enhancement" feature optional), since enhancement is not the way they have chosen. And since they are backed by Oracle, their voice has become louder.
        Probably there will be two levels of JDO spec : level one for Toplink, level 2 corresponding to JDO as we now know it.
        Anyway JDO is the thing all Java developpers have been waiting for, especially those who have tried EJBs : a well designed framework. And the transactionnal cache feature (in some products, like Lido) may lead to excellent perfs for most apps.
    • by haystor (102186) on Tuesday May 06, 2003 @12:18PM (#5891938)
      I've been using torque (from Apache, under the DB project).

      One row in the db equates to one object with all the appropriate getters and setters.

      I haven't been using Torque for anything too complicated, but it definitely passes the test of making the simple things simple, and area I find Java to be weak in.

      For instance:
      Torque.init("Torque.properties");
      Empl oyee emp = new Employee();
      e.setName("Dave");
      e.save();

      That's all there is to creating a row in the db. There are correspondingly simple operations for select, update and delete so long as you are working on one table at a time. Its a bit messier working with joins.

      Its also messy and poorly documented when doing work on the select side of the statement. While "select max(emp_id) from employees" is doable, its not as simple as it could be considering how common select max() is.
      • by MSBob (307239) on Tuesday May 06, 2003 @01:23PM (#5892711)
        Its a bit messier working with joins.

        That's a giveaway. If it can't deal with joins there is probably a lot more it can't deal with. Views, class hierarchies, transactions etc. I don't know torque but your example isn't enough to sell me on its simplicity.

      • by billtom (126004) on Tuesday May 06, 2003 @01:53PM (#5893068)
        JDO and Torque are both the same sorts of tools, Object-Relational Mapping (O-RM) tools. In the Java world there are also about a few dozen other O-RM tools (Apache Jakarta hosts two different ones even). (Note, we could split hairs here. JDO is an API specification, there are several vendors implementing it.)

        However, the difference between JDO and all the other ones is that JDO, for better or worse, is now the "standard" O-RM interface. Standard in the sense that it's the one Sun is promoting through the JCP. As such, it's probably the one in the long run that is going to dominate.

        I'm not entirely happy about that. Like yourself, we use Torque on our projects. But we're seriously considering changing to JDO (once the JDO implementations have stabilized, and maybe wait 'til JDO 1.1). Why? Implementation independance, tools support, potential employee skills availability. All the usual reasons why one might choose a "standard" interface over a "non-standard" one.

    • by Furry Ice (136126) on Tuesday May 06, 2003 @12:18PM (#5891947)
      I think your rant against EJB probably has more to do with entity beans than EJB in general. You can actually use JDO as the persistence layer from session beans, and that's pretty much what my company does. We wrote our own JDO-like code which works pretty well. Perhaps I'll pick this book up to see if it's worth switching, or maybe just to get some ideas to enhance our JDO-like code.
    • by serano (544693) on Tuesday May 06, 2003 @12:24PM (#5892001)
      [EJBs are] the bad apple that risks spoiling the whole J2EE barrel

      I thought that was Swing.
    • by Brian Blessed (258910) on Tuesday May 06, 2003 @12:27PM (#5892037)
      I've heard the opposite.

      Of course he's biased, but Marc Fleury (of JBoss) is very enthusiastic about CMP (Container Managed Persistence) v2.0 EJB's.
      In his "Blue" Whitepaper on the subject he wrote that the CMP (Container Managed Persistence) v1.1 of EJBs was seriously lacking in various critical aspects, and goes on to say the following:

      From Marc Fleury's "Why I love EJB's" [jboss.org] (PDF, page 7):

      In other words, if the CMP2.0 engine s applicability goes beyond EJB alone, why couldn t we imagine a CMP engine working on abstract plain old java objects? We will look at making it the default service for persistence in JBoss. In fact I would argue that CMP2.0 is doing what JDO failed to do, providing a robust and frameworkworthy persistence engine for java (once generalized). While it was widely used in designs a year ago, JDO will probably go down in history as the proverbial chicken that crossed the road when the CMP2.0 truck came along.

      - Brian
      • by awhite (179035) on Tuesday May 06, 2003 @12:54PM (#5892352)
        While it was widely used in designs a year ago, JDO will probably go down in history as the proverbial chicken that crossed the road when the CMP2.0 truck came along.

        If you read a lot of Marc Fleury's public comments carefully, it is clear that he doesn't know what JDO is. He equates JDO with Castor JDO [exolab.org], which is a relatively simplistic persistence solution that happens to have "JDO" in its name; it is not a Java Data Objects implementation. The quote above is a perfect example: the JDO spec is barely a year old! So JDO was not widely used a year ago: Castor, however, was getting a lot of publicity around that time.

        Fleury would do well to research the JDO spec, because a lot of the things he's proposing in his new vision for CMP are things that real JDO already does. JDO can persist vanilla Java classes with no code changes. Persistent fields and relations are completely transparent. Just declare a field of some other persistent type, and the relation is managed for you. Same with Collections and Maps and so forth (including collections and maps of relations to other objects). Data is lazily loaded as you access it, and change tracking is automatic. The runtime API for managing persisting objects consists of only a few classes. The query language looks just like Java boolean expressions. The whole system is elegant, but powerful. It stays out of your way. It's everything EJB is not :)
    • by pbur (88030) on Tuesday May 06, 2003 @12:43PM (#5892219)
      The one thing I think that kills Entity Beans for me is that they don't scale very well, in their design alone.

      For example: Say you have a findBy method that returns a 10000 row result set, but since it's EJB, it just returns the Primary Keys, then there's a second lookup for each of the 10000 keys to refresh the bean information. Now, take that to 100000. It really starts to get slow.

      I know no one said Entity Beans are a magic bullet, but when I think of "Enterprise Applications", I think large data sets and Entity beans clearly aren't made for that.

      Now, as other posters have said, I love Session Beans and use our own custom persistence to get the data in and out of the DB.
    • by javajedi (81810) on Tuesday May 06, 2003 @12:53PM (#5892339) Homepage
      I did a pretty extensive evaluation of both. Turned out the 2 technologies were very similar, as long as you use XDoclet with CMP Entity Beans. JDO's biggest advantage over CMP is built-in support for polymorphism and inheritance. CMP Entity Beans' biggest advantage over JDO is Container Managed Relationships. The code base for both sets of code was basically the same. JDO doesn't have declarative transactions, but I was able to simulate this using an Aspect. We ended up going with EJB, largely because it was more mature, and more good, open-source implementations existed (e.g. JBoss). There isn't even a full open-source JDO implementation yet.

      We are going live with the first release of this system on Friday, and the CMP Entity Beans are working like a champ. I'm really sick of people complaining about how terrible Entity Beans are. Everyone who does is either using a crappy implementation or doesn't understand how to use them right. There is nothing "tighter" about JDO.
    • by oops (41598) on Tuesday May 06, 2003 @12:59PM (#5892414) Homepage
      My main gripe with EJBs is that once you use them you're tied to a platform. That platform is an application server.

      Using JDO (or Hibernate or other solutions) allows you to deploy your solution inside an app container, inside a web container, or simply standalone.

      The biggest benefit I've seen from deploying standalone comes from unit testing (using JUnit). My most recent projects have all had sizeable sets of standalone functionality tests. Once those several hundred tests succeed in a standalone context I can then deploy into my container and perform further tests using Cactus. But the majority of testing takes place outside without any deployment grief or the extra pain of writing client/server (Cactus) tests.
    • by MSBob (307239) on Tuesday May 06, 2003 @01:21PM (#5892688)
      EJB is simple. Really. It isn't as bad as people say. Entity beans make sense once you read the spec and understand it.

      The sucky part of J2EE is deployment. If I don't have to look at another 500K deployment descriptor file I'll be a happy man. They moved so much functionality out of code into deployment descriptors that now it's more complicated to manipulate descriptors than code! We went full circle. Instead of keeping complexity in the code it has been shifted to XML i.e. the weakly typed, unchecked format that's responsible for 90% of J2EE project delays.

      Kill deployment descriptors and we'll all be winners. The tools to manipulate deployment descriptors have not materialised. It's time to cut the losses and ditch that XML madness in J2EE.

    • by deogee (671397) on Tuesday May 06, 2003 @01:37PM (#5892883)
      Try hibernate http://hibernate.bluemars.net.
      Inheritance, composition, lazy loading, proxies. Very easy. Sun seems to treat JDO as the black sheep of the J2EE family and who knows what they'll do with it. Besides, there's no truely compliant open source implementations availible.
    • JDO usability (Score:2, Informative)

      by elindauer (520825) <eric.lindauer @ h c m ny.com> on Tuesday May 06, 2003 @02:05PM (#5893191) Homepage
      I've been working with JDO essentially since it was released, and have found it to be a very effective tool. As with any technology, it takes some time to learn, and it has areas which aren't as transparent as you'd like them to be.

      I have always been the "JDO-guru" for my development team. As such, I've spent a lot of time trying to smooth out the various issues we've run into, so that other members of the team can work with this technology as transparently as possible. The main thrust of this work has been to make transaction handling easier, and to deal with PersistenceManagers. My company has been generous enough to allow me to open-source this work (which I've named "Stomp"), so if you are serious about using JDO, you may want to check it out [slashdot.org]. Even if you don't use the code here, there is a page explaining how Stomp works [sourceforge.net] which describes the motivation behind this toolkit, the problems we ran into, and how we solved them. You'll have to solve similar issues yourself if you use JDO, so this might be a good way to get a handle on what you'll face when you use JDO.

      This stuff works very well for us, but of course has the risk of being non-standard. Even if you don't use Stomp, the ideas presented may help you use JDO more effectively.

      PS Stomp is written to work with Kodo (from Solarmetric) but could easily be made to work with other JDO vendors. Write to me if you are interested.
    • by f00zbll (526151) on Tuesday May 06, 2003 @03:18PM (#5893867)
      I'm no expert on JDO, but I feel EJB's have gotten a really bad PR from mis-use. I've slammed EJB's myself when lead architects think using EJB's is a good idea when the app doesn't require transactional support. The thing is, JDO and EJB can work together, though not necessarily. If you have a multi-query/transaction process, JDO will provide some level of benefit, but it won't allow you to handle the transactional aspects. Again, most people don't have these kinds of requirements, but say you have to access 4 different databases. Each database has a slightly different data model. For a transaction to be valid, all the databases must be updated.

      Now with EJB's you can manage this using a standard framework and container. If you had to do this with JDO, you would need to either use it with EJB or write your own. The thing is, many architects don't understand when to use EJB's. Lead architects with the skills and technical chops know when to use EJB's. I've seen EJB's used well and use poorly. Those who use it well are programmers who understand EJB's at all levels, not just a high level over-view of what EJB's could do. One of the most common mis-uses of EJB is for simple non-transactional cache. Data that is updated weekly or monthly doesn't need EJB's and often is better off using a custom cache with specialized search/index algorithm to improve performance. This probably accounts for 50% of the apps. Without EJB's, doing transactions that require choreography would be a major pain and extremely difficult.

      Most developers have only had to deal with one database and one connection. In those cases, if the connection is interrupted, the transaction isn't commited. What happens when you have to connect to several databases? and the commit threshold varies between transactions? Those situation require something like EJB's where state is maintained in memory, so that selective or full rollbacks is possible. Don't believe what MS or other marketing driods preach. Serious software development is hard and takes dedication. It's not something that can be thrown together.

    • by rossifer (581396) on Tuesday May 06, 2003 @04:02PM (#5894410) Journal
      JDO is a massive step up from EJB entity beans, giving you inheritance, sophisticated state behavior, fairly low overhead (especially at the object layer) and several advantages besides.

      But JDO's goal, of insulating you from the database, means that you can't get to the database even if you need to. In my opinion, this limits JDO apps to the same "toy" class of applications that entity EJB's are limited to.

      For instance, the way JDO stores a polymorphic reference is to store the object id and the object type (as a text string with the fully qualified class name) as two separate columns in the referrer's table. That's horrible in several ways (including db bloat and the fact that you've lost most of the ability to report against the database), but because the JDO spec refuses to let you give it any hints, it has very few other options. This particular problem made JDO infeasable for the last app I worked on (a security manager that pulled in 30-50 million snort events per day). JDO would have doubled the database size, on a database that grew at 2-3GB/day!

      Other solutions, like Hibernate [bluemars.net] or OJB [apache.org] give you the ability to ignore the database if you so wish (by providing schema generating tools) but also give you the option of writing a great object model, writing a performant database schema, and then describing the best possible mapping between them. And believe me, when it comes time to make your application scalable to hundreds of simultaneous users and hundreds of millions of rows, you'll appreciate the ability to design the database yourself.

      JDO's real problem is that it pretends that there's no need for relational programming now that we've got object oriented programming and it's another restatement of the object-oriented database. Relational programming has several distinct advantages over OO programming in several problem areas, the most obvious being arbitrary search (which the OO model intentionally prevents with encapsulation). True object relational mapping tools don't make this mistake. They let the object model do what it's good at, the data model do what it's good at, and then help them talk to each other.

      One thing that JDO did do a good job of was the application interface. The query is nice and the rest of the semantics are clean. And luckily for the rest of the world, there's no reason why an ORM tool can't provide a JDO interface but do the mapping more intelligently. In all actuality, this is what will happen to JDO very shortly (if it already hasn't). The vendors will provide systems that comply with the spec and then customers will demand that they have more control over the db and mapping and each vendor will extend their implementation in some nonstandard way to give them that power.

      Regards,
      Ross
      • by rossifer (581396) on Tuesday May 06, 2003 @04:11PM (#5894510) Journal
        Sorry to reply to my own post, but the super killer that JDO doesn't manage and falls flat on is the update problem.

        Sometimes called "object evolution", "schema evolution", "schema upgrade", or a few other names, this is the problem you have when your objects (and therefore your schema) change from V1.0 to V1.1. Your customers will expect the upgrade to happen and the app to keep running, but a schema change will require that you do db manipulations to preserve their data across changing columns and tables.

        JDO gives you no help in solving this problem, and because it "helped you out" by keeping you away from the schema in the first place, you're in a worse position than you would be if you had written both versions of the schema. At least then you'd be able to know exactly what you changed and why. With JDO, you get the exciting and error prone task of reverse engineering what JDO helped you out with and hoping that you don't misunderstand something that corrupts your customer's data.

        Hiding the relational model doesn't help you at all and ends up biting you in the ass. As I mentioned in my previous posting, most vendors will quickly find that their customers need direct control over the database as well as the object model and "spec JDO" will only be used for toy and one-off applications.

        Regards,
        Ross
      • by awhite (179035) on Tuesday May 06, 2003 @05:36PM (#5895367)
        Actually most relational JDO implementations already let you bypass the JDO layer and deal with SQL when you want to, and let you map classes to an existing schema (or even generate classes and O/R mapping data from an existing schema). At least, I know you can do all this with Kodo JDO [solarmetric.com]. If you haven't checked out JDO lately, I'd say you should give it another shot. Keep in mind that the spec is barely a year old... implementations are adding features very rapidly.
        • by rossifer (581396) on Tuesday May 06, 2003 @06:11PM (#5895641) Journal
          That's what I figured would happen. But what I don't get is why being able to ignore the db is touted as one of the advantages of JDO. It's a serious problem in the spec which leaves you tied to the vendor-specific extensions.

          By leaving the gap in the specification, they prevent someone who's using JDO from easily swapping vendors. At that point, I still say that the application interface is nice, but I'll take an approach that blew off the cruft the first time around and did it the right way from the start.

          Regards,
          Ross
    • by Trinition (114758) on Tuesday May 06, 2003 @09:08PM (#5897413) Homepage
      A. There is nothing stopping a container from using JDO as its persistence implementation EJB Entity Beands.

      B. Entity beans also offer security, transactions and remoteness. None of that you get inherently with JDO.

  • JDO (Score:5, Insightful)

    by HunkyBrewster (578901) on Tuesday May 06, 2003 @12:07PM (#5891810)
    "In brief, Java Data Objects (JDO) insulates you from needing to know a lot about databases."

    First of all, I wouldn't want to hire that developer. Secondly, that is not entirely correct. O/R frameworks are useful in that they provide a consistent interface

    • Re:JDO (Score:3, Insightful)

      by rutledjw (447990) on Tuesday May 06, 2003 @12:33PM (#5892116) Homepage
      First of all, I agree - on both points. However, I think a batter description of JDO is that is provides a model which logically abstracts a persistence layer. Within the model it provides a good method of implementing DB interaction along the same "thought lines" of Entity EJB function.

      IMHO, the concept of encapsulating DB interactions (CRUD) in objects is a no-brainer. But the EJB implementation was out of control as far as overhead and complexity. JDO brings us back to the basics and eliminates a lot of that complexity and overhead...

    • by pmz (462998) on Tuesday May 06, 2003 @01:53PM (#5893066) Homepage
      "In brief, Java Data Objects (JDO) insulates you from needing to know a lot about databases."

      First of all, I wouldn't want to hire that developer.


      Agreed. The quote about JDO above is like saying VisualBasic frees programmers from needing to know, well, basically anything. It's marketing statements like this that get embedded in the minds of project managers, who, then, send a project free-wheeling into a pit of despair. I find it immensly disappointing that for each step the software industry takes forward, there is an equal step back.

      Sigh, are we (society) really truly moving forward with software? I don't really mean to be cynical, but I don't know the answer to that question any more.
    • by ansonyumo (210802) on Tuesday May 06, 2003 @02:44PM (#5893556)
      That's a gross generalization. A better statement would be "JDO insulates you from needing to know a lot about database implementations". That is, your businless logic need not be concerned with which SQL dialect it needs to use depending on which RDBMS you are talking to. JDBC syntax goes a long way towards insulating you from quirky non-standard syntax, but java to SQL type mappings are a different story altogether. When you know that you are always going to deploy against a certain flavor of database, then these aren't issues. However, for those of us that don't like to tell our bosses that we can't change database vendors without a major development effort, vendor neutrality is a hot button issue.

      What JDO provides is a "standardized" implementation of the abstraction that most software engineers would write to insulate business logic from persistence, rather than having JDBC code strewn throughout all layers of the application.

      The GUI coder needn't know how the objects are persisted any more than the server-side coder needs to know about widgets and whatnot. Somebody on your team needs to understand SQL, because even with JDO you are going to need to delve into some sort of SQL coding to get a workable solution (e.g. DDL for the production database, specialized queries not supported by the JDO specification).

      BTW my company uses TJDO [sourceforge.net] as the O/R mapper for our J2EE application. We were able to migrate from PostgreSQL to Oracle 8 in the period of a few days. YMMV, but that says a lot towards the utility of JDO and maintaining vendor neutrality.

      • by studerby (160802) on Wednesday May 07, 2003 @02:42PM (#5903504)
        Nice to hear that someone else is basing their business on TJDO (my company puts the the "T" in TJDO, though the bulk of active development is now coming from outside the co.)

        Your remark about "JDO insulates..." is spot-on; JDO isn't a panacea, by any means. It uses some resources that a hand-coded approach wouldn't, and naive programmers can tie a program in knots with bottlenecks or even resource deadlocks if they're sufficiently "inventive". However, being able to run the same code base against Oracle 8 or MySQL is worth a little cost, and the "inventive" programmer can screw things up in any language. It does seem to make persistence more mundane, freeing developer time for more work on business/feature logic.

  • by TheNarrator (200498) on Tuesday May 06, 2003 @12:09PM (#5891844)
    I looked into JDO and was excited. Here was a much simpler alternative to EJB. In EJB there are many many things that can go wrong during deployment of beans which leads and quite a bit of replication. YOu define your object once in the bean, once in the remote interface, once in the local interface, etc. It seems to take a while to debug. JDO is better but it requires a class file enhancer. Hibernate [bluemars.net] is a lot better. There is 1 config file that defines your whole object model and it requires no special class file enhancer. That and unlike EJB it supports inheritance in object models well.
    • by alienmole (15522) on Tuesday May 06, 2003 @12:25PM (#5892018)
      I agree - anyone looking for a Java solution for database access that makes sense, instead of just following the latest corporate craze for cookie-cutter coding, should check out Hibernate.
    • by mprudhom (111101) on Tuesday May 06, 2003 @12:42PM (#5892205)
      Hibernate [bluemars.net] is a lot better. There is 1 config file that defines your whole object model and it requires no special class file enhancer.

      That is precisely the problem with the majority of non-JDO persistence architectures that use standard reflection (Toplink, Hibernate, CocoBase, Castor). While people tend to get nervous about bytecode enhancement, it is just an additional step in the compilation process.

      Bytecode enhancement allows JDO to perform change tracking without intruding on the application. Reading 1000 objects in a transaction and changing a single one, a reflection based framework will need to perform comparisons on each and every field of each of the instances. JDO will just need to do a single one. Reflection-based persistence frameworks are fine for "hello world" applications, or if you do not mind intruding persistence details into the application, but for true transparent and scalable persistence, JDO is the way to go.

      Of course, there are many other comparison points between persistence frameworks, such as the degree to which JDO is datastore-agnostic, the number of JDO vendors vs. non-JDO vendors, the issue of JDO being based on an increasingly important standard, the lack of vendor lock-in, etc. Many of these issues are discussed on JDOcentral.com [jdocentral.com]

  • good book, bad topic (Score:2, Informative)

    by Anonymous Coward on Tuesday May 06, 2003 @12:10PM (#5891854)
    I read this book a couple weeks ago. It's a good book (some o'reilly's are essential, some were a waste of paper and ink, and some are good). However, Java Data Objects should be avoided if possible.


    I know that sounds like a harsh statement to the uninitiated. I'll admit, the idea sounds good. But the implementation is a headache and maintenance nightmare.


    I've worked with Java Data Objects for 3 years now, and everyone I know who has experience with it feels the same.

  • by product byproduct (628318) on Tuesday May 06, 2003 @12:13PM (#5891887)
    I read the title as "Java Android Complains".
  • by cpfeifer (20941) on Tuesday May 06, 2003 @12:14PM (#5891892) Homepage
    according to slashdot, the user 'java1dev' doesn't exist. What does this mean?
  • Annoying book (Score:2, Insightful)

    by Anonymous Coward on Tuesday May 06, 2003 @12:15PM (#5891903)
    I read this and thought that it was very much a downer on C++. In fact the authors even go so far as to suggest that Java is simply better in all but the rarest of cases. There is also a brief mention of JDK availability and also VMs in Red Hat, but I really didn't see how this was relevant.
  • by boxhead609 (671383) <prowe2@yahoo.com> on Tuesday May 06, 2003 @12:37PM (#5892157) Homepage
    I am concerned about learning another query language. Each has its limitations and that is why I was slow to adopt EJB-QL. EJB-QL is odd to learn and still not as feature rich as pure SQL. Now there's JDO-QL... yet another query language to learn. I found that in my previous projects, it is not that bad to embed SQL into DAO objects. You have complete power and control that way. You don't have to learn another QL, and you have the benefits of SQL.
    • by FatherOfONe (515801) on Tuesday May 06, 2003 @02:18PM (#5893315)
      The above post is by no means off topic! You bring up a great point. I believe in EJB session beans you can still write your own SQL. Not sure if that is what you meant by DAO objects...

      In my experience every one of these "Java Architects" seem to spew the same old crap.
      1. With this you don't care what DB you use.
      2. Speed won't be an issue because of cacheing.

      Yeah right... These are the same people that haven't written more than a 1,000 lines of code in their life.

      Do I think JBO deserves a look? Yep. Do I think that I may use it for some apps? Maybe, but I have the same huge concern that you have. If I have a SQL tuning problem, I can go to about a million different resources and get help with it. With another query language I am on my own.

  • by WndrBr3d (219963) * on Tuesday May 06, 2003 @12:38PM (#5892160) Homepage Journal
    I've said it once, and i'll say it again.

    These book reviews on Slashdot, at times informative, really just are letting people know about the book and not as much reviewing that.

    This demonstrated is that in the last two months, no book has received less than a 80% approval rating by the author (unless you rate a 'very good' as < 8). It's like Homer Simpson is writing these reviews, "This (book) gets my lowest rating ever, seven thumbs up."

    I mean honestly, a review needs to have a few lemons on its record. I think someone should review a Wrox book on Linux and have it summarized with, "This book really gobbled the cob. it wouldn't be fit to line the kitchen floor for my puppy to soil in the evenings."

    Instead of calling it 'Slashdot Book Review', it should just be called 'Slashdots list of books that rule'.

    That's just my opinion though, I could be wrong.
  • Alternatives (Score:5, Informative)

    by tdrury (49462) on Tuesday May 06, 2003 @12:41PM (#5892188) Homepage
    Before you commit to JDO or entity beans, do yourself a favor and also look at OJB [apache.org] and Hibernate [bluemars.net]. Both of these object-relational mapping (ORM) tools offer unintrusive presistence to your existing beans (unlike Toplink and Cocobase which require you use their collection types) and don't require you to run a byte-code mangler like JDO.
    • by dolanh (64212) on Tuesday May 06, 2003 @01:33PM (#5892834) Homepage Journal
      I agree with the Hibernate suggestion. However, I'm not so sure about the collection type comment. Yes, in a sense the interface is a standard Collections interface (Set, List, etc) but the actual underlying implementation is a Hibernate data type. IIRC, this was done to allow lazy-loading of collections.
    • by pmz (462998) on Tuesday May 06, 2003 @01:55PM (#5893088) Homepage
      Before you commit to JDO or entity beans, do yourself a favor and also look at OJB [apache.org] and Hibernate [bluemars.net].

      Okay, everyone, get it out of your system: reply, now, with the other 1,345 APIs that we should consider in addition to EJB, JDO, and, now, OJB and Hibernate. Don't be shy, now. Post!
    • fud again? (Score:4, Informative)

      by geoff_hendrey (655157) on Tuesday May 06, 2003 @02:32PM (#5893426)
      here we go with the FUD again. "Mangler"??? I suppose you consider javac a "mangler" or aspectj a "mangler". I think the "mangler" you refer to is the bytecode enhancer. What you forgot to mention is what the "mangler" does. Rather than scare people off, I'd like to explain the clear advantage to bytecode enhancement over reflection for dirty detection. Let's say you do a query which returns a single object. Your application then modifies a single field of the object and commits the transaction. Before commit you have to perform "dirty detection" to find out what fields have been dirtied, and need to be updated in the DB. If you don't use an enhancer you have to compare the object, field by field, with either a cached copy of the object, or worse, issue a select into the database to get the old values. The latter is particlularly bad not just for the obvious performance hit, but because it forces the table or rows to be locked for the duration of the transaction, thus making optimistic transactions impossible. Now imaging your select returned 100 objects, or 1000 objects. With an enhancer, the bytecodes for 'putfield' and 'getfield' are replaced with calls to the bvendor provided state manager. The JDO driver knows instantly what fields were dirtied, needs to keep no cached copies and never hits the database with a select before update. Furthermore, with enhancement you don't force the user to extend any classes. There is zero intrusion on the domain model. I understand that Castor, Hibernate, etc. are good open source projects, and very viable. I do, however, think that JDO is elegant and has advantages, on paper at least, over other methods.
  • How do you .. (Score:3, Insightful)

    by 1337_h4x0r (643377) on Tuesday May 06, 2003 @12:42PM (#5892198)

    Tell it which objects are mapped to which tables? And what about objects that map to multiple tables? Seems like you'd still have to have SOMEONE who knew how to do a proper database schema to set up your object structures and mappings, and make the database itself. :)

    That said, this would free your developers from having to be intimately knowledgable about your database schema, which, if you have done any outsourcing, you would recognize the benefits of right away.

  • Hard problem... (Score:4, Insightful)

    by Hard_Code (49548) on Tuesday May 06, 2003 @01:00PM (#5892420)
    There are several Object-Relational mapping packages for Java out there. Hibernate is another one.

    However, I have to say, that I have not found any complete O/R mapping package that implements everything transparently. In specific, I'm talking about recursive map structures, and "long transactions". Most of these packages are aimed towards short lived transactions on one object, or on a unidirectional tree of relationships.

    I sunk absolutely OBSCENE amounts of time and effort into trying to make various packages work with a many-to-many self-recursive database structure only to realize it cannot currently be done with the packages out there. I would be glad to be proven wrong.

    I would love to be able to keep a cache of a recursive map structure in memory (indefinately!) and have modifications automatically cascade the required updates to all nodes and revoke/expire any checked out nodes.

    Finally I gave up trying to cache the actual structure in memory and now I just cache data, descend over the structure in the database for each request (it's not so bad, it turns out to be rather fast anyway).
    • by pmz (462998) on Tuesday May 06, 2003 @02:04PM (#5893185) Homepage
      I would love to be able to keep a cache of a recursive map structure in memory (indefinately!) and have modifications automatically cascade the required updates to all nodes and revoke/expire any checked out nodes.

      Haven't some of these problems already been solved in the RDBMS systems themselves? Are databases really so slow (meaning misapplied, misdesigned, and misconfigured) that all these layers upon layers upon layers of APIs and abstractions are necessary to get the job done?

      Why not just two racks of computers: one rack with a database cluster, whose database vendor has solved all the data integrity issues, and one rack of apache webservers with gool ol' fashioned CGI programs? Wouldn't the raw simplicity of this configuration pay for itself? Stick a god-awful fast interconnect in there and bandwidth shouldn't be a limiting factor. I've never done this--it's just an idea.
      • by Hard_Code (49548) on Tuesday May 06, 2003 @03:45PM (#5894188)
        Like I said, the performance wasn't all that bad anyway. Object-Relational Mapping does not (typically) solve a performance problem, it solves the impedence mismatch between Object Oriented Programming (the way most anything important is written these days) and relational databases and their declarative[ish] languages like SQL.

        I also had the good fortune that the application I was writing had VERY little data, so the iteration was very fast, even when hitting the db each time, and was 99.999% read-only (and my final write solution was "blow away the cache entirely and don't even bother with integrity").
      • by alienmole (15522) on Tuesday May 06, 2003 @04:02PM (#5894419)
        Haven't some of these problems already been solved in the RDBMS systems themselves? Are databases really so slow (meaning misapplied, misdesigned, and misconfigured) that all these layers upon layers upon layers of APIs and abstractions are necessary to get the job done?

        The goal is to make life easier and more productive for developers, and to handle more complex systems with less code, less repetition, and just generally better-engineered solutions.

        Database languages, i.e. the vendor-specific varieties of SQL such as Oracle's PL/SQL, suffer from a number of problems. For a start, they're proprietary, non-standard, vendor-specific languages. Most database users are seriously tied to their database - in most cases, it would be easier to switch server OS than switch databases.

        In addition, database languages are not very good programming languages. They've evolved from SQL to become poor, legacy-ridden general-purpose languages which suffer from most of the spaghetti-code problems which languages like Java were designed to alleviate. Not that Java is the most wonderful language ever, but it's a lot better than PL/SQL or TSQL for many tasks.

        So, one major goal for these mapping and abstraction layers is to allow a more robust programming language to be used, to provide better functionality and reduce or eliminate dependency on specific databases.

        Why not just two racks of computers: one rack with a database cluster, whose database vendor has solved all the data integrity issues, and one rack of apache webservers with gool ol' fashioned CGI programs? Wouldn't the raw simplicity of this configuration pay for itself?

        This can work fine for some applications, when the database design requirements are fairly straightforward. It doesn't scale well to more complex applications. Also, even if you're not writing incredibly complex applications, a good mapping layer can still simplify things, reduce the amount of code you have to write, and give you greater flexibility.

        • by pmz (462998) on Tuesday May 06, 2003 @04:29PM (#5894718) Homepage
          The goal is to make life easier and more productive for developers, and to handle more complex systems with less code, less repetition, and just generally better-engineered solutions.

          Has this actually occurred in practice? I have yet to see it. The explosion in the number of APIs with these goals has arguably made the developer's job much much harder, where the learning curve leading to informed decision making is becoming impassable. Specialization of jobs is not improved from before, where the "Oracle developer" is replaced with a "J2EE developer" or, worse, an "EJB developer". And, now, there needs to be both the "Oracle developer" and the "J2EE developer", because both systems are so complex that one person can hardly do both jobs competently. Using something like J2EE or .NET hardly relieves the project of needing its database-specific expertise.

          Net reduction in complexity: nil. All we have accomplished is sweeping the pile of complexity to the other side of the room and adding new staff to document where the pile went.

          Most database users are seriously tied to their database - in most cases, it would be easier to switch server OS than switch databases.

          Similarly, most (insert API name) users are seriously tied to their (insert API name). Again, in most cases it would be easier to switch the server OS than switch (insert API name). Additionally, the lock-in is now not only database-specific but application-server-specific, as well, because I have yet to see an abstraction layer so well concieved that the database doesn't leak through.

          So, one major goal for these mapping and abstraction layers is to allow a more robust programming language to be used, to provide better functionality and reduce or eliminate dependency on specific databases.

          But they add literally millions of lines of code that is opaque to its users, tens of thousands of nuances, and hundreds of new things to learn. How can this be called progress, when complexity is actually going up rather than down?

          I really think the software industry needs to step back and take a breath.
          • by alienmole (15522) on Thursday May 08, 2003 @02:50PM (#5912254)
            I really think the software industry needs to step back and take a breath.

            I think it needs more than that. Where my perspective is coming from, though, is getting work done within the confines of the current software industry.

            Has this actually occurred in practice? I have yet to see it.

            I've seen it in some systems, and I try to develop systems like that. However, it doesn't happen automatically, by any means. A big aspect is being sensible about choice of tools. E.g., the obvious one that most people know: avoid EJBs.

            Similarly, most (insert API name) users are seriously tied to their (insert API name).

            Yes, but there's a difference. If you imagine an ideal system, it would involve an application written in code which relies on an abstraction boundary that's very close to the needs of the application. Put simply, SQL does not provide such an abstraction - too low-level - whereas writing code that uses objects that are transparently persisted, can.

            But using an object persistence mechanism, your code is going to be dependent on that mechanism, as you say. Given that, it's important to make sure that the API you depend on is at least to some extent, under your control. One way to do that is by using an open source framework. Yes, your code will become dependent on that framework, but you have more control over the code you're dependent on, and you won't be writing large amounts of code in a poorly-designed proprietary language over which you have no control whatsoever.

            But they add literally millions of lines of code that is opaque to its users, tens of thousands of nuances, and hundreds of new things to learn. How can this be called progress, when complexity is actually going up rather than down?

            That's where choice of tools comes in. Avoid overly complex systems, and use open source frameworks. Two systems that I've been working with are Resin (as the application server) and Hibernate [sf.net], for transparent persistence. The codebases of both don't add up to a million lines, and both are well-conceived and well-written. Code doesn't have to be dependent on Resin unless you particularly want it to, because it's a standards-compliant Java application server - a commodity item, essentially. Code will certainly become dependent on a tool like Hibernate, though. So let's examine that.

            Before I began using Hibernate, I worked on and used a number of home-grown persistence frameworks (developed by clients of mine, in some cases with my assistance) of varying degrees of sophistication. Why do companies develop such frameworks, since they're only going to suffer from the issues you mention, of complexity etc? The answer is that the need arises from the kind of code you end up writing without them - for example, you get repetition, which creates maintenance problems, and you want to factor that repetition out. So it's pretty natural for even many naive projects to end up with something that qualifies as a persistence framework, even if only an unsophisticated, simple one. These libraries tend to make life easier for the projects that rely on them, but they tended to be one-off efforts which had many shortcomings.

            For companies using such frameworks, switching to a comprehensive open source solution is a no-brainer - it provides better functionality all around, has a larger developer base, and the source is still available for customization, tuning etc. if neccessary.

            In this area, a big reason the problems you're concerned about exist is because we rely on databases which impose severe restrictions on the kind of code that can be run "within" the database, but running "outside" the database entails a huge semantic gap between the client language and the database. Middleware such as persistence mechanisms are a fix designed to bridge this gap. Do they add to total complexity? Sure. But they also reduce complexity in some important areas.

            Besides, what's th

    • by Aapje (237149) on Wednesday May 07, 2003 @03:28AM (#5899169) Journal
      Have you tried EOF [apple.com] (part of WebObjects [apple.com])? It uses an extensive caching structure and cascades modifications. It's not completely transparent though, but I doubt that any package can provide that given the complexities of such a solution. This [stepwise.com] explains how to extract EOF for use in a pure Java app.
  • by Agave (2539) on Tuesday May 06, 2003 @01:01PM (#5892439) Homepage
    Object-Relations Mapping isn't very new, even in the realm of Java. Apple, TopLink, CocoBase, have been there for years without JDO. I haven't had much time to evaluate JDO but I'd be surprised if it's as well designed or as comprehensive as Apple's Enterprise Objects Framework [apple.com] and EOModeler [apple.com].

    EOF is available with WebObjects [apple.com] which is a much easier way to build 100% Java web applications than any jsp/ejb solution.

    in summary:
    Object-relational mapping - good.
    WebObjects/EOF - good.
    JDO - undecided.
  • by pcraven (191172) <paul&cravenfamily,com> on Tuesday May 06, 2003 @01:16PM (#5892625) Homepage
    I tried putting JDO in an app I was using. Seemed pretty cool initially. The OQL through me off at first. Despite being around for a really long time (10+ years), there was little documentation on the Object Query Language.

    This got me into what I thought was the biggest problem. Too much abstration. JDO ran too slow for me. And rather than making things simple, it made them more complex.

    Bottom line: Object databased and query languages have been around for a long time. Few people use the, prefering the relational model. Despite the fact that Object databases are sexy. There is a reason for the fact there are few apps built this way.
    • by awhite (179035) on Tuesday May 06, 2003 @01:26PM (#5892749)
      I believe you are confusing JDO with something else. JDO does not use OQL. It has its own query language that looks exactly like Java boolean expressions. For example:

      name == "John" && address.zip == 77096 && nickNames.contains ("JJ")

      Also, JDO is certainly not slow. In fact, a good implementation with object caching and (if relational) prepared statement pooling and statement batching can be as fast or faster than staight JDBC.

      You might be thinking of Castor JDO, which has "JDO" in its name, but is not a Java Data Objects implementation.
      • by pcraven (191172) <paul&cravenfamily,com> on Tuesday May 06, 2003 @01:37PM (#5892884) Homepage
        I was thinking of Castor JDO. Thank you, you are wise.
      • by Jhan (542783) on Tuesday May 06, 2003 @02:03PM (#5893174) Homepage

        Also, JDO is certainly not slow. In fact, a good implementation with object caching and (if relational) prepared statement pooling and statement batching can be as fast or faster than straight JDBC.

        Thank you ever so much for elaborating on a long standing joke of mine.

        More than ten years ago I heard the first cries of "... given the complexity of current processors, modern C compilers outperform hand coded assembly in most cases.".

        Then "... just-in-time compilation allows Java to be optimized further than statically compiled languages such as C".

        (Missing link, anyone have a sound bite?) JDBC is faster than using SQL directly with the database.

        A good object caching scheme (and statement pooling) will make JDO faster then JDBC.

        So, my new JDO application is faster than a hand-coded assembler application! Yay! Only, why does it take 10 minutes to... <THUNK>

        Thought Police! Circulate! There's nothing to see here!

  • OJB is better... (Score:3, Informative)

    by JohnnyCannuk (19863) on Tuesday May 06, 2003 @01:29PM (#5892787)
    While JDO is interesting, the Apache OJB (Object Relational Bridge) [apache.org] project is even better. It provides a JDO implementation as well as an ODMG impelemtation and a low level PersistenceBroker API. Lots of choice. More than one way to do things, allowing the developer to trade-off make trade-off when they are appropriate. It is fully transactional and supports the latest JDO as well as ODMG specs.

    And it can be used to persist objects transparently...you can set it up to persist objects you already have and completely control how the object relation mapping takes place in a few config files.

    We've used it on projects since November, and I don't think we'll ever go back to Entity Beans. This project allows you to choose when you would like to use byte code enhancment techniques (JDO) or reflection techniques(ODMG) or even combine the two.

    Best of both worlds.

  • by Billly Gates (198444) on Tuesday May 06, 2003 @01:46PM (#5893004) Journal
    Question:

    Is Jdo a clone of Ado?

    It seems to provide the same kind of functionality.
    If sun was smart they would release newer libraries to compete with C#.net as well. You can create apps with similiar functionality like Microsofts petshop demo with 1/4th the code compared to java. Bussiness customers notice this. Especially if project deadlines are always a problem. The quicker something is done the better.

    • Re:ado?? (Score:2, Informative)

      by f00zbll (526151) on Tuesday May 06, 2003 @02:19PM (#5893321)
      Bussiness customers notice this. Especially if project deadlines are always a problem. The quicker something is done the better.

      I'll bite. Although this statement may seem accurate it is not. Let's take for example companies that provide application services, be it insurance, financial or enterprise resource management. There's nothing wrong with hardcoding everything and removing abstraction layers all together, if the application will stay that way for 1-2 yrs. Having said that, none of the projects I've worked on had static requirements. If anything, the requirements change rapidly. Hardwiring everything in the petshop demo mean you'll have to change 50-80% of the code to support a new feature.

      putting in abstraction layers increase code size right. adding comments to your code so that it is self-documenting and easy to maintain adds to the code size also. It's great model of development if your goal is to charge as much as possible and spend 80% of your time maintaining and fixing the system. It only works if you don't have competitors. If some one else take 15% more time to build the same system, but their maintenance cost is only 25%, you'll loose the battle in the long run. So the quicker something is done isn't necessarily better.

      If sun was smart they would release newer libraries to compete with C#.net as well.

      This statement is mis-informed. there are plenty of libraries that provide better standard compliance to XML, SCHEMA, and SOAP in Java than Microsoft. Try to do Object-relational mapping that follows standard OR techniques. What I mean by this is, take relational data and map it to an object hierarchy which reduces repetition/duplication of values. Guess what, if you use the stock VS.NET tool it only generate flat tables. This means rowsets that have similar/same columns will be duplicated. this is because ADO flattens everything and doesn't maintain OR mapping, therefore the Schema tool in VS.NET generates flat tables.

      I could be wrong, but every time I've tried using VS.NET schema tool with database tables that is what it does. The only way to get around that is to build your own OR mapping and write the schema by hand using complexTypes instead of elements the way VS.NET does it.

  • Hibernate [bluemars.net]

    It uses XML files to map between databases and Java. Good support for transactions, and more complicated cases.

    A good overview can be found here [bluemars.net]...
  • by awhite (179035) on Tuesday May 06, 2003 @06:29PM (#5895805)
    If you want to get a technical feel for JDO, Solarmetric [solarmetric.com] has an online document that covers all the spec basics here [solarmetric.com]. It's not as in-depth as a full JDO book, but it covers JDO concepts pretty nicely in about 40 pages (if it were printed).
  • by Trinition (114758) on Tuesday May 06, 2003 @09:16PM (#5897466) Homepage
    In my databases 102 class in college (yeah, I passed databases 101), we covered heirarchial, network, and relational databases. More recently, I've learned of object oriented databases (for a free, 100% Java poor-man's OODB, see XL2 [xl2.net]). From everything I've read about OODBs, they would be better solution than RDBMSs for 90% of the stuff I've seen as a Java programmer.

    The negatives I've heard from people in coversation are "they're not as fast", "there ae no tools", etc. BUt each of these are either false, not entirely true, or jyst due to immaturity:

    Too slow Actually, because there is no impedance mismatch (converting from related rows into an Object, and converting the data types between disparate systems), they can be faster than an RDBMS. Where you might have to pull up a person record, and then their home address record, convert their homepage into a URL object, etc... in an OODBMS, your data is (can be) already in the proper Object format. You wouldn't needs things like JDO.

    Tools no available Well, the haven't been around for as many decades as RDBMSs either. And, one of the other things that makes RDBMS tools so numerous is that they have a standard language, SQL. However, you must still rebuild what the data means in your reporting system separately from your online system. In an OODBMS, you would theoretically only build the Classes for the Objects once, and they would have with them the business rules.

    Any thoughts? I'm not an OODBMS bigot, but I'm trying to be an advocate in the hopes that it will have some truly educational dialogue.

    • by John Bayko (632961) on Wednesday May 07, 2003 @11:42AM (#5901460)
      I've never understood what's special about OO databases - as far as I can tell, they're just either making the rows into objects, or allowing objects to be stored as column data. It may make interfacing with the database easier from an external language like Java, but doesn't actually enhance the database itself - the expressiveness is the same. It may even be worse, if you can't access the data within object columns for selects.

      Something that is a genuine enhancement to databases is deductive databases, which attempt to simplify query writing by using defined relations to write the query for you.

      Note: in set theory that relational database theory is based on, sets are equivalent to database tables, tuples are records, and attributes are columns.

      Many of the concepts come from Prolog, which essentially defines the relationship between sets of tuples (with unnamed attributes), in such a way (using logical implications) that you can write a question, and the interpreter will figure out how the sets are joined based on the defined relationships (if they are), and return the first matching answer (or nothing, if no relationship can be found, or nothing matches the query conditions).

      Many people have tried to make Prolog more database-like, with persistant data. However, relational databases can be made more Prolog-like. It wouldn't be hard - foreign key constraints provide much the same information as Prolog implication statements. It would not be that hard to generate a query based on known foreign key relationships - e.g. for "SELECT PERSON.NAME, COMPANY.ADDRESS", the interpreter could figure out as well as a human that what the relationship between PERSON and COMPANY is without an explicit WHERE clause.

      I also don't think this would take much more time to execute, since generating the query only uses the table definitions, and it only has to be done once per query. A small number of entities to search and some caching should make it unnoticable in practice.

      I suppose the question is whether it's worth the effort, when SQL is so simple. I think so, mainly because I think SQL is an abomination, but that's just me - I don't work with databases at the moment.

      • by Trinition (114758) on Wednesday May 07, 2003 @02:51PM (#5903589) Homepage
        OODBMS are not supposed to objectivy rows, and tables. In fact, XL2 (whcih is the only OODBMS I've worked with) does nothing of the sort. It's more like serializing the graph of objects and references you have in memory to disk.

        Now, perhaps some OODBMSs are really object-relational mapping solutions behind the scenes, but I know for a fact that XL2 is not. I've been through the source code and was awed at the simplicity. It is very much like a snapshot of memory on disk.

        Now XL2 is primitive in that it doesn't have an Objective query language. You must query it yourself. In pseudo-code, you would work with it like this:

        XL2Database db = new XL2Database(...);
        AddressBook addresses = (AddressBook)db.getRoot();
        Person trinition = addresses.findByUsername("Trinition");
        db2.startT ransaction();
        trinition.setKarma(50);
        db2.endTra nsaction();

        Note that the AddressBook class defines "findByUsername". Internally, it could just be a HashMap. Or, if you wanted to be slick, it would be an XL2Map (which can lazy-load individual members). But the point is, I didn't write a query like "SELECT * FROM USERS WHERE USERNAME='Trinition'", convert the result into an object, change an attribute, and then take each attribute of the User object and stick it into a Prepared statement and update the record.

        It is much simpler. Now, if you have 50 million users in your AddressBook, and XL2Map might not be the most efficient mechanism for performing lookups. Relational databases rock at that sort of thing.

        But then again, as I said before. OODBMSs are still young, and XL2 especially is poor-man's OODBMS.
        • by John Bayko (632961) on Wednesday May 07, 2003 @03:35PM (#5904159)
          That sounds roughly like what I though, though maybe the terms differ. The object "type" or class corresponds to a set (or table, in RDBMS), and each object of that class is a tuple (or record or row). The object references are basically dataless foreign keys (constraints are implicit - the reference is added when the tuple/object is created, and garbage collection ensures that the object is never destroyed as long as the reference is still there, where in a RDBMS you explicitly delete tuples, and it raises an exception when the reference is still there - messy, but conceptually the same thing).

          The nice thing about what you describe looks like you can follow the relations explicitly in program code. You can do that in RDBMSes, but there is no direct mechanism to support it (specifically syntax) - they're directed to automated query resolution to such an extent that trying to bypass it is actually harder (in other words, there's no way to avoid SQL comlexity when you don't want it). But that's a problem with SQL and RDBMS implementations, there's no reason you couldn't get your mind out of the SQL/Tables gutter and make a nice RDBMS.

          In essense, the OODBMS you described is basically an RDBMS, but without automated queries. Actually, pre-SQL RDBMSes used to be like that. A lot more work to program (think COBOL) - the difference seems to be the text/table-oriented focus compared to using structs/classes for the same thing.

Uncompensated overtime? Just Say No.

Working...