Thanks Alex. I was beginning to think I was in the minority for questioning ORM. :)
I started work on a "persistence layer" which didn't even try to do ORM. It was simply a tool to take the grunt work out of writing joins and handing the result sets. You could create a bean which represented the rows, then programatically define your requirements. Which I think is the key here.. We often use ORM by runtime criteria. We want X,Y,Z which could be defined at runtime. We don't have the luxury of hand crafting the select. And even if it's compile time, this is something we expect the ORM to handle well. So anyway, in my experiment, you could say, I want an Airline Booking, The Passenger's Phone number and the Cruising Altitude of the aircraft that is scheduled for the booking. Essentially a set of joins. But it didn't then try to map that out to an object model, and would handle ad-hoc updates of the fields. I guess you could do that with hibernate today, but bypassing some of the ORM.. but it was fun to tinker. :) On Jul 17, 9:22 am, Alex Turner <[email protected]> wrote: > What I've seen is a fundamental mismatch in fetching strategies > between RDBMS over TCP and Java Objects to Local cache. Most java > aps, and ORMs even fetch a single entity at a time, which is horribly > inefficient to an RDBMS over TCP, but works fine to a local Cache > which can pre-fetch large batches of objects (hence @BatchSize in > hibernate, and query threading in Eclipselink etc..). > > How do you solve this? You can't. If people want ORM, then they will > fetch by singles, or end up massively over-fetching trees of data all > the time, whereas if people use straight up Queries, they will be able > to have a DBA rephrase to fetch as much and as little as possible in a > single query to improve performance, which is normally very fast > assuming your database is configured correctly instead of searching > for that n+1 query 'bug'. > > Honestly - based on my experience to date with Hibernate/Eclipselink, > I'm really not sure what the problem is that ORM solves. It's not > decreasingly complexity, that's for sure, and I've spent massive > amounts of time debugging my mappings, particularly when it comes to > legacy databases, so they sure as hell haven't saved me time. In fact > I think since switching to ORM, the time to develop an application has > increased dramatically. > > Alex > > On Thu, Jul 16, 2009 at 6:56 PM, Christian > > > > Catchpole<[email protected]> wrote: > > > On Jul 16, 10:21 pm, Martin Wildam <[email protected]> wrote: > >> Are you thinking of "persistence" basically in relation with "objects" > >> or in general in the way of making your data persistant? > > > Well both really. I guess the dream would be a nice model for the > > business but also a clean connection into the application (rather than > > an ORM). > > > Perhaps my initial post was an overreaction. But I am a "lets make it > > better" kind of guy. I'm not saying throw the baby out with the bath > > water. On another thread I asked (because I don't know), do these > > supposed object data bases still provide many of the relation features > > of SQL databases. Defining column widths seems a little antiquated... > > although i guess there is an argument for defining max lengths. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
