Java Data Objects 165
| 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.
suggestion (Score:5, Insightful)
Yes, it can be found by searching the web, but it's just extra comfort brought by a small database tweak.
Re:suggestion (Score:2)
Re:suggestion - also add a link to addall (Score:2)
They even show how to link right to a book price search with ISBN, etc.. how to link [addall.com].
Ryan
JDO vs EJB Entity Beans? (Score:5, Insightful)
(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.)
Re:JDO vs EJB Entity Beans? (Score:1)
I've started using Castor which aint quite JDO, but very close and a damn site easier than EJBs...
Re:JDO vs EJB Entity Beans? (Score:5, Informative)
Re:JDO vs EJB Entity Beans? (Score:3, Insightful)
Re:JDO vs EJB Entity Beans? (Score:3, Interesting)
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...
Re:JDO vs EJB Entity Beans? (Score:2)
So, who gave that baby the gun? EJB is hardly at fault, here.
Re:JDO vs EJB Entity Beans? (Score:2)
However, I do feel that the overhead, complexity and hence pitfalls of ENTITY EJBs (Stateless Session beans are fine, really) made a bad situation MUCH worse
Re:JDO vs EJB Entity Beans? (Score:2)
Toplink is becoming JDO (Score:3, Informative)
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.
Re:JDO vs EJB Entity Beans? (Score:5, Informative)
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");
Emp
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.
Re:JDO vs EJB Entity Beans? (Score:2)
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.
Re:JDO vs EJB Entity Beans? (Score:3, Insightful)
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.
Re:JDO vs EJB Entity Beans? (Score:4, Insightful)
Re:JDO vs EJB Entity Beans? (Score:2)
Re:JDO vs EJB Entity Beans? (Score:2)
Re:JDO vs EJB Entity Beans? (Score:1)
I thought that was Swing.
Re:JDO vs EJB Entity Beans? (Score:2)
I think Swing is more at risk of having spoiled the whole "Java on the desktop" barrel (after AWT already made it smell kinda funny...)
Re:JDO vs EJB Entity Beans? (Score:1)
Re:JDO vs EJB Entity Beans? (Score:3, Informative)
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
Re:JDO vs EJB Entity Beans? (Score:4, Interesting)
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
Re:JDO vs EJB Entity Beans? (Score:3, Interesting)
Is there an open source implementation of JDO?
Re:JDO vs EJB Entity Beans? (Score:3, Informative)
And this one is free for non-commercial use: Libelis [libelis.com]
Also, there are a number of open source implementations that are "in-progress" -- Apache's Object Relational Bridge [apache.org], etc.
This is one thing about Java that OSS advocates should appreciate -- open specs, multiple implementations. Standardising less than 10% of your APIs without commitment to allow competing implementations to the rest of the platform is simply showmanship.
Re:JDO vs EJB Entity Beans? (Score:1)
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.
Re:JDO vs EJB Entity Beans? (Score:3, Informative)
Re:JDO vs EJB Entity Beans? (Score:3, Informative)
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.
Re:JDO vs EJB Entity Beans? (Score:3, Interesting)
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.
Re:JDO vs EJB Entity Beans? (Score:4, Insightful)
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.
Re:JDO vs EJB Entity Beans? (Score:2, Informative)
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)
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.
Re:JDO vs EJB Entity Beans? (Score:2, Interesting)
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.
Re:JDO vs EJB Entity Beans? (Score:3, Informative)
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
Re:JDO vs EJB Entity Beans? (Score:2)
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
Re:JDO vs EJB Entity Beans? (Score:2, Informative)
Re:JDO vs EJB Entity Beans? (Score:2)
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
Re:JDO vs EJB Entity Beans? (Score:2)
I'd put that number closer to 20%. Personally, I've never developed an app where I could ignore the app after the "dog and pony" prototype had served it's purpose. Don't get me wrong, I know there's a place in the world for Perl, so I know there's a place in the world for small database-aware Java systems that don't deal with a lot of data and rarely if ever change the schema.
But I've never developed one of them. Every time I've needed a persisted store in one of my projects, I've had high concurrency demands, a need to scale to deployments as large as a branch of the US Military, or a Fortune 100 company, or... and there's never a simple query requirement. It's always some path following, weighted edge graph evaluation model that can be done in the object model if you've got big enough iron, or in a fairly small database if you've got the relational programming skills. And I don't notice anyone correcting my observation about schema evolution (though I was hoping that someone would and I would learn something new). If you haven't had to push a schema change down against a 100GB database with a backup that takes three days to finish restoration (in case you screwed up), you haven't lived.
What approach? JDO is the standard. The only other options are certain vendor's products.
Three comments:
1) The great thing about standards is that there are so many to choose from. (blatantly stolen, I know
2) JDO is a standard, not the standard. Besides all of the vendors aiming for defacto standard status, ODMG has had an ORM standard too. Been around for a few years, actually. The OJB project already fully implemented it in Java and OJB works pretty darned well.
3) JDO isn't a very mature standard. More of an experimental effort at this point. I see JDO as Sun's first pass at fixing JDBC's big problems. As an architect/developer who's been around the ORM block a few times, this first pass has some nice contributions to the ORM space (and don't think they haven't noticed), but got stuck in the OO-limited perspective.
The sooner Sun drops the "JDO let's you ignore the database and do the neat stuff!", the sooner they'll be on the right track to the right balance. JDBC was too far the other way, but I'm confident they'll get it right one of these days. After trying everything else
Regards,
Ross
Re:JDO vs EJB Entity Beans? (Score:2)
B. Entity beans also offer security, transactions and remoteness. None of that you get inherently with JDO.
JDO (Score:5, Insightful)
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)
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...
Re:JDO (Score:2)
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.
Re:JDO (Score:2)
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.
Re:JDO (Score:2)
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.
Java Data Objects are nice but Hibernate is Better (Score:5, Informative)
Re:Java Data Objects nice but Hibernate Better (Score:2)
Re:Java Data Objects are nice but Hibernate is Bet (Score:3, Insightful)
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]
Re:Java Data Objects are nice but Hibernate is Bet (Score:2)
good book, bad topic (Score:2, Informative)
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.
Re:good book, bad topic (Score:3, Informative)
FUD. The specification was released only one year ago [jcp.org].
and everyone I know who has experience with it feels the same.FUD. See JDOCentral.com [jdocentral.com] and TheServerSide [theserverside.com] for real-world discussions.
Re:good book, bad topic (Score:1)
Bzzzt! Thanks for coming. the spec has been around a lot longer than that. I was using Castor [exolab.org] back in early 2001.
I won't bother boring you with my experiences using it.
Re:good book, bad topic (Score:3, Informative)
Repeat.
Caster is NOT Java Data Objects
I'm too much of a Star Trek fan (Score:4, Funny)
[OT} java1dev slashdot user? (Score:2)
Annoying book (Score:2, Insightful)
Re:Annoying book (Score:2)
Another Query Language (Score:1, Informative)
Re:Another Query Language (Score:2)
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.
Well, for those who missed it (Score:5, Interesting)
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.
Re:Well, for those who missed it (Score:1)
It really makes the most sense to post the reviews of books that are actually good. If I'm interested in a new topic, I really don't care to read or wade through a detailed review of a book that is bad. Just give me one or two good books to start me in the right direction.
If I'm buying a car, sure list what's good and bad for my money, but if I'm looking for a book on new technology I'm into, just send me the ones people are passionate enough about to send in a glowing review.
Re:Well, for those who missed it (Score:3, Insightful)
To have an honest book review, you should read the full book. Unfortunately, it's very difficult to fully read a book when it sucks.
So maybe this is the reason slashdot readers review only books that rule...
Alternatives (Score:5, Informative)
Re:Alternatives (Score:2)
Re:Alternatives (Score:2)
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!
Re:Alternatives (Score:2)
Just do it with the database vendor's db specific interface API.. CLI for DB2, for example.
Better yet, just use low-level ODBC calls.
Or, better yet, do it in ADO, or DAO or OLE-DB
fud again? (Score:4, Informative)
How do you .. (Score:3, Insightful)
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)
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).
Re:Hard problem... (Score:2)
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.
Re:Hard problem... (Score:2)
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").
Re:Hard problem... (Score:2)
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.
Re:Hard problem... (Score:2)
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 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.
Re:Hard problem... (Score:2)
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
Re:Hard problem... (Score:2)
Apple's Enterprise Object Framework (Score:2, Informative)
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.
JDO, not for me (Score:2)
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.
Re:JDO, not for me (Score:1)
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.
Re:JDO, not for me (Score:2)
Re:JDO, not for me (Score:2)
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!
Re:JDO, not for me (Score:2)
OJB is better... (Score:3, Informative)
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.
ado?? (Score:2)
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)
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.
Re:Yes (Score:2)
Re:ado?? (Score:2)
OleDB is the data access technology. ADO is the object-oriented, vendor-neutral specification for transparent data persistence. It guarantees important levels of support for transaction management, identity management, and caching.
Sounds like JDO.
Re:ado?? (Score:2)
Hibernate is a lighter, nicer implementation (Score:2)
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]...
Online JDO Overview (Score:2, Insightful)
What's after relational? (Score:3, Interesting)
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.
Re:What's after relational? (Score:2)
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.
Re:What's after relational? (Score:2)
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.start
trinition.setKarma(50);
db2.endTr
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.
Re:What's after relational? (Score:2)
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.
Re:Important Question (Score:1)
A better way to describe that pronounciation would be 'JAY DOO'. But I think 'JAY DOH' is better
Re:erm (Score:1)
a funny comment: 1 karma
an insightful comment: 1 karma
a good old-fashioned flame: priceles
My sig:
Some twit/nerd/geek that thinks he's witty, but has a mispelling in his sig: (Even better)
Re:erm (Score:1)
Re:Still in love with Java? (Score:1)
I use several Java applications on the desktop that are NOT slower than molasses, IDEA from IntelliJ would be a perfect example. Maybe not a flame, definitely not the truth, but most likely a troll
Re:Still in love with Java? (Score:3, Interesting)
Ever heard of
From my experience, Java is much nicer for enterprise-level web applications than anything MS offers. As for desktop apps, it's fruitless to write desktop apps in Java when 95% of your customers are running Windows and MS has meager support for Java, at best. So you may not find Java apps on store shelves, but you don't have to look very hard to find desktop Java in the open source community.
Almost every program I run at work is Java-based and smokes the Windows-only counterparts most people use. So please don't go spouting your "truth" on something you know nothing about.
Re:Still in love with Java? (Score:2)
From my experience, Java is much nicer for enterprise-level web applications than anything MS offers. As for desktop apps, it's fruitless to write desktop apps in Java when 95% of your customers are running Windows and MS has meager support for Java, at best.
Dude, you should see Java on MacOS X. It makes Java apps running on the Windows JVM look like native code. Even the SWT libraries of Eclipse run like molasses.
Re:Still in love with Java? (Score:2)
Speed, try JBuilder (every C++ user complains about how horrible java is, then they code in JBuilder, and bitch again. Then you tell them JBuilder is built COMPLETELY with java, not C++, and they don't believe you).
And Java is enormous in the enterprise setting (online banking systems, etc...). It wasn't meant to be something you sell in a store. Why? Too easy to decompile. Its mostly used in internal only or backend websites.
If you truely care to argue about this (instead of a blatant troll), I'd be happy to argue back.
Re:Still in love with Java? (Score:2)