|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 106
Messages: 106
Messages: 106
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Criticism of Java Persistence Frameworks
"Most of applications are database-driven and need to access tables, modify data. Although there are many questions about persistence frameworks, we need them a lot when developing applications. Otherwise SQL codes scatters across applications causing an ugly and unmanageable application. Persistence frameworks build a database layer and separates concerns. Java Persistence solutions are divided into two branches. One is Java standard solutions; JDBC, EJB, JDO. The other is ORM (Object-relational Mapping) frameworks; Hibernate, Toplink, Enterprise Object Framework, iBatis etc.
Let me ask the basic question that everybody somehow asks himself “Isn’t there any other solution to persistence problem simpler and more powerful?” I have been reading many problem news about this issue. Last one was Sun’s attempt to simplify EJB. In fact, this is why new frameworks will never end."
Ibrahim Levent describe the 23 most common pitfalls of Java Persistence Frameworks:
1- “Object-Relational Impedance Mismatch” is not solved
2- Frameworks don’t suit application architecture needs (Web or Desktop)
3- XML usage should be immediately abandoned
4- Database Metadata is not utilized
5- Object Query Languages are a wrong path
6- Don’t throw SQL away, it is not enemy
7- Multiple data source dilemma
8- Why persistent objects are so weak (POJO)?
9- Poor Transaction Management
10- Heavy Object Caches
11- Wrong Locking Methods
12- Persistence API could be simpler
13- Bytecode manipulation problems
14- Unnecessary OID (object id) columns in tables whereas PK columns are enough
15- Inheritance has no meaningful usage
16- Primary and foreign keys are held in accompanying new classes causing many unnecessary classes
17- Missing cluster support
18- Missing database events
19- Missing authorization
20- Missing dynamic rules
21- Missing object modeling tools for code generation
22- Missing audit trailer
23- Missing persistent object debugging utilities
http://fromapitosolution.blogspot.com/2008/12/criticism-of-java-persistence.html
|
|
|
Message #280695
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Choose your question!
Instead of solving every problem at once, one should ask the proper question: what tool|framework helps me to solve my problem? Btw. what is my problem that needs to be solved? :)
More problem space: database shards, database triggers, non-normalized data refreshes... everything depends on your problem space...
|
|
|
Message #280696
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
criticism of criticism
Seems to me this mostly shows the author has no updated knowledge and understanding of what modern persistence tools and standards are.
Anyway:
* point 18 is interesting but requires something at the DB level,
* 19 is sadly true, security in general should be part of persistence layers
* 20 requires some explanations,
* 22 is true and could be easily added.
|
|
|
Message #280698
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Criticism of Java Persistence Frameworks
Yes, but the industry basically gave it a thumbs down in the 90's: object database management systems.
One eliminates the "impedance mismatch" problem by using the same data model in the database as in the application. Ask any old Smalltalker that utilized GemStone if they had problems with persistence.
Now, there were plenty of criticisms of ODBMSs, some of them valid, and most of them FUD. However, a decade later here we sit bitching about the same 'ol problems. Had we given ODBMs another decade to mature, especially in the area of administration tools, then we'd be having a different conversation.
IMHO, when we use an RDBMS to provide a backing store for an object-oriented application, we're using the wrong tool for the job. We'd generally be better off using an ODBMS to provide seamless persistence, and extract the data into a RDBMS for reporting, archiving, etc.
Mark
|
|
|
Message #280701
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Criticism of Java Persistence Frameworks
Mark,
I haven't asked myself the OP's question since I started using db4o. What I have been asking myself is why I wasn't using it earlier.
But I know the answer and you've summed it up pretty well I think.
Any green-field project I work on now gets db4o as the default db implementation, unless there are some specific requirements. Usually these are to do with integrating with legacy RDBMS db4o remains the main database provider.
The only change I am considering moving forward is using something like JPOX to abstract the fact I'm using db4o in order to future proof my architecture.
Since I also work with OSGi a lot of the time, separation of concerns are second nature. In fact, a lot of the points on that list I can happily ignore because the combination of OSGi and db4o resolves those "issues" out of the box.
Cheers,
Chris
|
|
|
Message #280704
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Criticism of Java Persistence Frameworks
Mark,
I haven't asked myself the OP's question since I started using db4o. What I have been asking myself is why I wasn't using it earlier.
But I know the answer and you've summed it up pretty well I think.
Any green-field project I work on now gets db4o as the default db implementation, unless there are some specific requirements. Usually these are to do with integrating with legacy RDBMS db4o remains the main database provider.
The only change I am considering moving forward is using something like JPOX to abstract the fact I'm using db4o in order to future proof my architecture.
Since I also work with OSGi a lot of the time, separation of concerns are second nature. In fact, a lot of the points on that list I can happily ignore because the combination of OSGi and db4o resolves those "issues" out of the box.
Cheers,
Chris
I started using Versant 1.6 back in the early 90's with our first large C++ application, and then switched to GemStone in the mid 90's when we moved from C++ to Smalltalk.
At the time, the relational vendors kicked their FUD into high gear. They were going to provide all the object-oriented features that the ODBMSs provided, but in a mature product. 'Just you wait.
And we waited. And waited. And we're still waiting.
The desire for seamless persistence did not go away, and thus were born the OR persistence frameworks, which certainly helped, but didn't solve the problem.
Now, don't get me wrong. Relational databases are the right tool for the right job. But, like a man with a hammer looking at every problem as a nail, they're often used for the wrong job.
Unfortunately, most organizations can not afford to pay for 2 different database systems, and the training that goes with it. Versant had an interesting white paper a number of years ago that pitched the idea of using its ODBMS for "transient" persistence, e.g. support clustering, failover. This type of persistence was useful for short-term storage of application-level objects.
If your business had a need for long-term storage of enterprise class entities, e.g. customer data, orders, etc., you'd rightfully utilize a relational database.
Of course, what was missing was the tools necessary to easily and transparently extract the relational data from the object database.
Mark
|
|
|
Message #280711
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
ODBMS
That why persistence is important, because you want to directly manipulate your business object model, whatever the underlying storage is.
|
|
|
Message #280716
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
persistence layer on top of ODBMS
Whatever the underlying database is, you need a persistence layer, to isolate you from the storage layer. Persistence should not be limited to ORM, even if ORM is a very important subset of it.
The success of RDBMS came from a reaction against previous db technologies, where database models where too coupled with application data models, making ad-hoc reporting difficult.
You can imagine having two different application object models consuming the same object database model.
|
|
|
Message #280745
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: criticism of criticism
Seems to me this mostly shows the author has no updated knowledge and understanding of what modern persistence tools and standards are I agree and responded on his blog last night.
|
|
|
Message #280747
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SUGGESTION: Direct Persistence Layer in Berkeley Database
One problem with JPA is that it is a beautiful solution for very specialized problems. Otherwise, it's overkill for the vast majority of business application's I've written in the past.
I recently discovered sleepycat/Oracle's Direct Persistence Layer on Berkeley Database (both are Open Source projects). It uses @Entity annotations like JPA, but has only a subset of the functionality and is many orders of magnitude faster. There are too many benefits to enumerate in this post, but when I switched my project off JPA to DPL, it sped up development and made the application dramatically faster.
http://www.oracle.com/technology/documentation/berkeley-db/db/index.html
In the end, I found myself questioning the need for RDBMS on the vast majority of my projects. I've spent a decade refining my database expertise, both because I enjoy solving data problems and because every employer wanted their solution on an RDBMS (usually Oracle) because it's familiar and conventional, despite the fact it was the slowest piece and added great cost to the project.
I think in the next few years, many developers are going to start questioning the role that DBs perform in their applications. How much sense does it make to model your data in Java and relationally when the vast majority of your persistence code is simply rebuilding the exact data you put into the system at a previous date? Are you really using the RDBMS in the way it was intended to be used? Are you using the full JPA-QL or SQL?
Many people clearly need JPA and an RDBMS, particularly in data warehousing situations. However, most simple applications could get by with a subset of the JPA, especially if it made their application's persistence code 10-100x faster.
|
|
|
Message #280752
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: persistence layer on top of ODBMS
The success of RDBMS came from a reaction against previous db technologies, where database models where too coupled with application data models, making ad-hoc reporting difficult.
You can imagine having two different application object models consuming the same object database model.
I read somewhere a prediction that service orientation, if adopted generally, would remove a lot the need to separate the persisted data model from the application data model.
I believe it when I see it but it does pose an interesting question. If you design your application to expose everything through accessible interfaces (web service or otherwise) is there value in using a relation database for your underlying persistence model?
|
|
|
Message #280754
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SUGGESTION: Direct Persistence Layer in Berkeley Database
One problem with JPA is that it is a beautiful solution for very specialized problems. [...] I recently discovered sleepycat/Oracle's Direct Persistence Layer on Berkeley Database (both are Open Source projects). It uses @Entity annotations like JPA, but has only a subset of the functionality and is many orders of magnitude faster.
JPA is a specification and simply defines an API, you need to look at the specifics of your JPA implementation you're using for why that is the case. There is nothing inherent in the spec that is for "very specialized problems". In the same way as there is nothing in the JDO spec that is for anything specialized - that is down to the implementation to define as thin or thick a layer as is needed for the particular problem.
Out of interest : which JPA impl persisting to Berkeley DB, compared against DSL persisting to Berkeley DB ?
--
Andy
DataNucleus
|
|
|
Message #280756
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SUGGESTION: Direct Persistence Layer in Berkeley Database
One problem with JPA is that it is a beautiful solution for very specialized problems. Otherwise, it's overkill for the vast majority of business application's I've written in the past.
I recently discovered sleepycat/Oracle's Direct Persistence Layer on Berkeley Database (both are Open Source projects). It uses @Entity annotations like JPA, but has only a subset of the functionality and is many orders of magnitude faster. There are too many benefits to enumerate in this post, but when I switched my project off JPA to DPL, it sped up development and made the application dramatically faster.
http://www.oracle.com/technology/documentation/berkeley-db/db/index.html
In the end, I found myself questioning the need for RDBMS on the vast majority of my projects. I've spent a decade refining my database expertise, both because I enjoy solving data problems and because every employer wanted their solution on an RDBMS (usually Oracle) because it's familiar and conventional, despite the fact it was the slowest piece and added great cost to the project.
I think in the next few years, many developers are going to start questioning the role that DBs perform in their applications. How much sense does it make to model your data in Java and relationally when the vast majority of your persistence code is simply rebuilding the exact data you put into the system at a previous date? Are you really using the RDBMS in the way it was intended to be used? Are you using the full JPA-QL or SQL?
Many people clearly need JPA and an RDBMS, particularly in data warehousing situations. However, most simple applications could get by with a subset of the JPA, especially if it made their application's persistence code 10-100x faster.
Welcome to the world of object databases. After nearly 20 years, people are still yearning for the simple persistence model that they provided.
Imagine extending Java's memory model to disc. Objects that are reachable from a root object eventually migrate to persistence storage, and may have copies in various cache levels along the way. A shared distributed cache allows multiple VMs to share common objects without having to go to disc.
Other than defining transactional boundaries, persistent objects behave no differently than any other object. Every POJO is made persistent if it's reachable from another persistent object. No mapping language. No special base class. No persistence-capable classes.
This was the basic model of GemStone nearly 20 years ago.
The biggest change I would make would be to add transactional awareness to in-memory objects. Basically, I would make transactions and locking (pessimistic and optimistic) first-class features of Java. Mixing persistent objects and transient objects in the same transaction when you have to perform a rollback is a pain, as you have to implement your own transaction log for the transient objects.
Mark
|
|
|
Message #280780
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I'm happy with Hibernate
perhaps not perfect (there's always room for further improvement), but works fine for my apps.
|
|
|
Message #280781
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
GORM?
To what extent does GORM mitigate or remove some of the original poster's issues? GORM is going to be a standalone technology more easily usable outside of Grails, though I have to say I'm not sure exactly what that will look like. I've only ever used it inside of Grails, but it did seem to make things easier and, to my mind, seems to address most of his concerns (#12 specifically)
http://www.groovymag.com/latest
for groovy and grails developers
|
|
|
Message #280905
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
ORM = solution in search...
Well, it seems we're back few years ago when persistence was generating flame wars on TSS.
Hope we're still passionate, but we will be more civilized this time ;-)
Not sure however, when we see how some "conditional racers" are trying to put some oil on the fire.
|
|
|
Message #280906
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
new ODBMS today?
Welcome to the world of object databases. After nearly 20 years, people are still yearning for the simple persistence model that they provided.
Imagine extending Java's memory model to disc. Objects that are reachable from a root object eventually migrate to persistence storage, and may have copies in various cache levels along the way. A shared distributed cache allows multiple VMs to share common objects without having to go to disc.
Other than defining transactional boundaries, persistent objects behave no differently than any other object. Every POJO is made persistent if it's reachable from another persistent object. No mapping language. No special base class. No persistence-capable classes.
This was the basic model of GemStone nearly 20 years ago.
The biggest change I would make would be to add transactional awareness to in-memory objects. Basically, I would make transactions and locking (pessimistic and optimistic) first-class features of Java. Mixing persistent objects and transient objects in the same transaction when you have to perform a rollback is a pain, as you have to implement your own transaction log for the transient objects.
Mark
I truly believe in transparent persistence, but I would not design a new database today like the old ODBMS did in the past.
A DBMS cannot just be memory objects graphs stored on a disk, you need some kind of abstraction between the physical storage model and the memory model. This vision of persistence has been one of the reasons for ODBMS rejection.
You must have a very effcient storage layer, able to store any kind of modern models (without the limitations of the relational models).
That storage must have powerful admin, query features, support for transactions, etc. Then you will need some kind of external layer to define all the data access, security and higher level concepts. This layer could also be responsible for data integration and should publish any kind of data flows for heterogeneous consumers: POJO, .Net objects, XML and support multiple standards.
It seems to me that's at least the direction taken by some leading persistence technologies.
|
|
|
Message #280909
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SUGGESTION: Direct Persistence Layer in Berkeley Database
One problem with JPA is that it is a beautiful solution for very specialized problems. Otherwise, it's overkill for the vast majority of business application's I've written in the past.
I recently discovered sleepycat/Oracle's Direct Persistence Layer on Berkeley Database (both are Open Source projects). It uses @Entity annotations like JPA, but has only a subset of the functionality and is many orders of magnitude faster. There are too many benefits to enumerate in this post, but when I switched my project off JPA to DPL, it sped up development and made the application dramatically faster.
http://www.oracle.com/technology/documentation/berkeley-db/db/index.html
In the end, I found myself questioning the need for RDBMS on the vast majority of my projects. I've spent a decade refining my database expertise, both because I enjoy solving data problems and because every employer wanted their solution on an RDBMS (usually Oracle) because it's familiar and conventional, despite the fact it was the slowest piece and added great cost to the project.
I think in the next few years, many developers are going to start questioning the role that DBs perform in their applications. How much sense does it make to model your data in Java and relationally when the vast majority of your persistence code is simply rebuilding the exact data you put into the system at a previous date? Are you really using the RDBMS in the way it was intended to be used? Are you using the full JPA-QL or SQL?
Many people clearly need JPA and an RDBMS, particularly in data warehousing situations. However, most simple applications could get by with a subset of the JPA, especially if it made their application's persistence code 10-100x faster.
I guess the performance improvement you experienced is rather coming from the different database technology than from the API around it. The relational model has many benefits but also some drawbacks in terms of performance and expressiveness of models. You would certainly achieve the same level of performance with the this kind of storage engine coupled with JPA or JDO.
By the way there is nothing in JDO today preventing from implementing it for non-relational databases. The same could apply to JPA, even if this one has been more focused on ORM than JDO.
|
|
|
Message #280910
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: persistence layer on top of ODBMS
I also recently read that blog entry from Martin Fowler, saying that with SOA services will be responsible for their persistence and the integration will be done outside the database.
http://martinfowler.com/bliki/DatabaseThaw.html
That makes sense.
I think the key point is to have a strong Data Services based upon a reliable persistence / integration layer. Once you'll have that you will be able to select the best storage technology for each service.
That's also something discussed here:
http://www.dataservices-connection.com/
|
|
|
Message #280912
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: GORM?
I don't know I am having a hard time using the mapping clause to make my grails app understand an existing schema. i am missing SQL already
Would I be able to easily build, for instance, a application where a user chooses any subset of a hundred or so available columns and then the database makes the appropriate left-joins to display those in a table?
|
|
|
Message #280913
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Problem with ODBMS
Imagine extending Java's memory model to disc. Objects that are reachable from a root object eventually migrate to persistence storage, and may have copies in various cache levels along the way.
Imagine complex reports working several days instead of seconds...
RDBMSes force you to normalize your data model and also allows you to have very fast ad-hoc queries and reports.
|
|
|
Message #280914
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Disappointed
I was feeling nostalgic for 2003-ish and hoping that this thread would turn into a flame war :) Gavin, care to get the party started?
[Actually I am glad that we've moved beyond those days]
|
|
|
Message #280921
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Criticism of Java Persistence Frameworks
I would broaden this criticism to include Web Frameworks in Java as well.
The gap between stateless HTTP and OOP is nearly as wide as the gap between OOP and RDMS.
This is why we have at least 6 major Web Frameworks for Java...and all of them have serious drawbacks (from my experience anyway).
But yes, your concerns are valid. There is a mis-match, and I'm not sure if it can be address in a seamless way. (Without switching to Object Databases)
|
|
|
Message #280925
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Problem with ODBMS
Imagine extending Java's memory model to disc. Objects that are reachable from a root object eventually migrate to persistence storage, and may have copies in various cache levels along the way.
Imagine complex reports working several days instead of seconds...
RDBMSes force you to normalize your data model and also allows you to have very fast ad-hoc queries and reports.
Which is why I stated in an earlier post that you extract the enterprise data into a relational database for reporting and archiving. One must use the right tool for the job, and adhoc reporting is certainly the strength of relational databases.
Mark
|
|
|
Message #280929
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ORM
ORM = solution in search of a problem. Hibernate is a waste of time and resources.
I wouldn't go that far to criticize hibernate or any other ORM tool, but in reality I almost agree with you. I haven't seen any real world project, where you can achieve 100% with any ORM tools, there are many occasions where you have to roll over your sleeves and right plain JDBC code, or may be even stored procedures. At the end you have a code base that is Mombo-Jumbo of every thing. The only reason you see these ORM tool so popular is first because of the IT marketing (Good for me, bad for my clients, but why the hell I care if they buy every thing I feed them:-)), and second because at the end we all work for money and developers thinks one more framework will look good on their resume at least to find a new job. Alas what a shallow world we developers live in.
RJ
|
|
|
Message #280930
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Problem with ODBMS
Which is why I stated in an earlier post that you extract the enterprise data into a relational database for reporting and archiving.
And the best tool for archiving data from ODBMS into RDBMS is ...ah... ORM. And after you've added ORM for data synchronization you'll start wondering why the heck do you need ODBMS?
Been there done that...
If you need complex analytics you'd be better off using classic RDBMS+ORM. It'll save you a lot of pain in the end.
Though maybe systems with continuously updated persistent _reports_ (like CouchDB) will change this situation.
|
|
|
Message #280933
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Persist with Terracotta
Imagine extending Java's memory model to disc. Objects that are reachable from a root object eventually migrate to persistence storage, and may have copies in various cache levels along the way. A shared distributed cache allows multiple VMs to share common objects without having to go to disc.
Other than defining transactional boundaries, persistent objects behave no differently than any other object. Every POJO is made persistent if it's reachable from another persistent object. No mapping language. No special base class. No persistence-capable classes.
Mark - That is an amazingly precise description of what Terracotta provides. If you are a Java programmer, you may want to check it out http://www.terracotta.org
|
|
|
Message #280935
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still Love SQL
I mean after using Hibernate (call it nightmare for people who love SQL so much) with Annotation I felt you have two layer of bread to eat what's inside.
Everybody keep talking about complex Java frameworks (they are monsters nothing less) but not a single framework or ORM offers simplicity for developer.
I mean scripting languages are doing better in enterprise world. If you look at ROR and PHP they are doing so well (Python as well) & wonder how long these giant frameworks will sale.
|
|
|
Message #280936
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Criticism of Java Persistence Frameworks
That is quite a list of criticsms.
Personally I have found Cayenne has a achieved pretty good balance and addresses most of these issues.
1- “Object-Relational Impedance Mismatch” is not solved
This really depends upon how you want to design your solution. If you go down the Rich Domain Model design path, welcome to a world of pain. If you treat entity classes as relatively simple representations of the relational model things are much more managable.
2- Frameworks don’t suit application architecture needs (Web or Desktop)
Cayenne has good support for web and desktop usage, you don't need additional support from Spring to use the framework.
3- XML usage should be immediately abandoned
Cayenne uses XML extensively for managing the data model. However it has a very good Cayenne Modeller GUI tool, so its easy to manage.
4- Database Metadata is not utilized
Cayenne exponses the underlying database meta data contained in the model, data types, null rules, relationships etc. which is good for building UI which can use this information
5- Object Query Languages are a wrong path
No comment.
6- Don’t throw SQL away, it is not enemy
Agree, SQL is very powerful for queries. Cayenne has very good support in its Named query capability.
7- Multiple data source dilemma
It supports multiple data source, and resolve them automatically for you. Very nice
regards Malcolm Edgar
|
|
|
Message #280937
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ORM
I haven't seen any real world project, where you can achieve 100% with any ORM tools
Look harder or in the right place.
|
|
|
Message #280938
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ORM
ORM = solution in search of a problem. Hibernate is a waste of time and resources.
I wouldn't go that far to criticize hibernate or any other ORM tool, but in reality I almost agree with you. I haven't seen any real world project, where you can achieve 100% with any ORM tools, there are many occasions where you have to roll over your sleeves and right plain JDBC code, or may be even stored procedures. At the end you have a code base that is Mombo-Jumbo of every thing. The only reason you see these ORM tool so popular is first because of the IT marketing (Good for me, bad for my clients, but why the hell I care if they buy every thing I feed them:-)), and second because at the end we all work for money and developers thinks one more framework will look good on their resume at least to find a new job. Alas what a shallow world we developers live in.
RJ
Conversely, I could say that's an "opinion" of SI marketing (manual coding and tuning of SQL statements is a nice business).
I could also "say" that I've seen real big applications using ORM in production. We can argue like that for hours.
What's the problem if you cannot avoid some 5% specific JDBC coding in a project if the ORM layer helped you for the other 95% ?
I don't think that using an ORM imposes you to forget database programming. It is just an assistant.
|
|
|
Message #280939
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Problem with ODBMS
Which is why I stated in an earlier post that you extract the enterprise data into a relational database for reporting and archiving.
And the best tool for archiving data from ODBMS into RDBMS is ...ah... ORM. And after you've added ORM for data synchronization you'll start wondering why the heck do you need ODBMS?
Been there done that...
If you need complex analytics you'd be better off using classic RDBMS+ORM. It'll save you a lot of pain in the end.
Though maybe systems with continuously updated persistent _reports_ (like CouchDB) will change this situation.
Sometimes when you need real performance in production you have to consider non-relational technologies.
By the way, even when you consider raw analytics, some former RDBMS gurus now claim that relational model is not so suitable, see for instance Stonebraker's Vertica.
|
|
|
Message #280940
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ORM
ORM = solution in search of a problem. Hibernate is a waste of time and resources.
I wouldn't go that far to criticize hibernate or any other ORM tool, but in reality I almost agree with you. I haven't seen any real world project, where you can achieve 100% with any ORM tools, there are many occasions where you have to roll over your sleeves and right plain JDBC code, or may be even stored procedures. At the end you have a code base that is Mombo-Jumbo of every thing. The only reason you see these ORM tool so popular is first because of the IT marketing (Good for me, bad for my clients, but why the hell I care if they buy every thing I feed them:-)), and second because at the end we all work for money and developers thinks one more framework will look good on their resume at least to find a new job. Alas what a shallow world we developers live in.
RJ
Speak for yourself. I've been using Hibernate for projects ranging from simple web apps to web-based products for *years*, right hear in the real world.
What a shallow developer who thinks he's seen it all when he's seen very little.
|
|
|
Message #280941
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SUGGESTION: Direct Persistence Layer in Berkeley Database
By the way there is nothing in JDO today preventing from implementing it for non-relational databases. The same could apply to JPA, even if this one has been more focused on ORM than JDO.
Hi Eric,
So, true. Which is why the Versant Object Database implements JDO and JPA ( in alpha ).
In the end, I think Istanov who got it right. It's asking the right questions that counts. There is no one tool ,it's choosing the right tool for the job that counts.
Things are getting increasingly complex, much more data, significantly more concurrency. When your questions involve these things, object databases have more and more relevance. You can see by our latest today that these factors are driving increasing business in the object database direction. Smart developers will learn more about this technology .... and I know already you are an expert ;-)
Cheers,
-Robert
Versant Corp
|
|
|
Message #280942
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Criticism of Java Persistence Frameworks
I would broaden this criticism to include Web Frameworks in Java as well.
The gap between stateless HTTP and OOP is nearly as wide as the gap between OOP and RDMS.
This is why we have at least 6 major Web Frameworks for Java...and all of them have serious drawbacks (from my experience anyway).
But yes, your concerns are valid. There is a mis-match, and I'm not sure if it can be address in a seamless way. (Without switching to Object Databases)
That's true. We also now have impedance mismatch between relational, object and hierarchical (XML) models. Seems to me that object models are the most complete (the 2 other ones are subset), form the execution and modeling point of view. Relational is good from the storage/query point of view. And hierarchical (XML) is good for data exchange. It might be that there is no best model for everything.
So we'll eventually need ORM, OXM and XRM and maybe more later. That's the point. Mapping has to be universal. Converting models is key in our business. That's what we do every day, when we use a compiler, we convert from one model to another. Even runtime execution is a conversion layer.
|
|
|
Message #280944
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SUGGESTION: Direct Persistence Layer in Berkeley Database
By the way there is nothing in JDO today preventing from implementing it for non-relational databases. The same could apply to JPA, even if this one has been more focused on ORM than JDO.
Hi Eric,
So, true. Which is why the Versant Object Database implements JDO and JPA ( in alpha ).
In the end, I think Istanov who got it right. It's asking the right questions that counts. There is no one tool ,it's choosing the right tool for the job that counts.
Things are getting increasingly complex, much more data, significantly more concurrency. When your questions involve these things, object databases have more and more relevance. You can see by our latest today that these factors are driving increasing business in the object database direction. Smart developers will learn more about this technology .... and I know already you are an expert ;-)
Cheers,
-Robert
Versant Corp
It is true that with the SOA era, it will become possible to decide which storage techno will best suit specific requirements. Could be an RDBMS, an ODBMS or something else (Cloud Database, SimpleDB...). It seems there is currently a trend saying that specific problems require specific database technologies. Could be a new chance for ODBMS or not. We also thought in the past that XML or Internet could have been a chance for ODBMS and it didn't.
|
|
|
Message #280945
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SUGGESTION: Direct Persistence Layer in Berkeley Database
Oops missed a char somewhere in that one..
You can see in our latest
Press_Release today.
-Robert
Versant Corp
It seems your missing character infected my answer. After viral technologies, viral posts...
|
|
|
Message #280946
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SUGGESTION: Direct Persistence Layer in Berkeley Database
Yes, I think SOA can. In the end, it will come down to cost of computing. If there is a good model in your SOA and you choose an OODB as the transactional storage, then you simply give away the CPU cycles required when making the RDB choice....not just in the database tier, but the SOA layers ..remember that's where the mapping/unmapping occurs. This is really where you save a few kilo watts.
In the end, the scale of our compute problems are diving us toward "cloud" type solutions. But, again, it comes down to cost, even in the cloud.
-Robert
Versant Corp
|
|
|
Message #280947
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SUGGESTION: Direct Persistence Layer in Berkeley Database
Weird .....wonder if it continues ;-)
|
|
|
Message #280948
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SUGGESTION: Direct Persistence Layer in Berkeley Database
By the way there is nothing in JDO today preventing from implementing it for non-relational databases. The same could apply to JPA, even if this one has been more focused on ORM than JDO.
Hi Eric,
So, true. Which is why the Versant Object Database implements JDO and JPA ( in alpha ).
Exactly!. And why DataNucleus Access Platform also implements JDO/JP ... for RDBMS, db4o, NeoDatis, XML, Excel, LDAP and JSON. Has been in production for several months.
|
|
|
Message #280949
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Criticism of Java Persistence Frameworks
I would broaden this criticism to include Web Frameworks in Java as well.
The gap between stateless HTTP and OOP is nearly as wide as the gap between OOP and RDMS.
This is why we have at least 6 major Web Frameworks for Java...and all of them have serious drawbacks (from my experience anyway).
But yes, your concerns are valid. There is a mis-match, and I'm not sure if it can be address in a seamless way. (Without switching to Object Databases)
The issue with web frameworks is another one, the underlying technology is fundamentally broken and needs to be replaced.
Lets face it, http is stateless, the only input controls allowed are input fields, text areas, combo boxes drop down boxes and buttons, with not functionality at all except for being able to send events and submit forms!
Above that to cover modern UIs you have to rely on vendor specific extensions because the vendors all chose to ignore the W3C standards and roll their own thing (to roll in cash)
Add to that broken model for scripting, a so lala language with a central document singleton no isolation at all on language level and on DOM level and you are in for hell.
Webframeworks and the sheer number of them in existence is a proof for my conclusion above try to simplyfy this mess, and face it it does not really work out because in every framework the underlying broken technology shines through!
|
|
|
Message #280951
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JPA can be very very straightforward
I made myself that basic question many times and came to this conclusion:
- if you have an object-oriented mind set and you want the framework to handle collections and persist automatically on more tables when you call a save method then either you use an object-oriented database (like db4o for instance) or you use a full ORM. In the latter case I would stay with JPA since it's the standard way and you can choose between implementations (Hibernate, EclipseLink among the others).
- but (and this is maybe the case you - like me, and many other developers - are thinking about) if you want a flat approach and you prefer to handle each insert, update, delete and select with a per-table approach then JPA is always a straightforward option. I didn't understand this concept in the past and for this reason I have used iBATIS a lot (which is not an ORM, but just a mapper). It is indeed very easy to learn and use, but still you have to write XML mapping files, create factory/utility classes and so on. JPA instead can be much more direct if you want to handle each table separately. See
http://www.censnet.it/articles/cap03.htm
for an example. It is not a recent article, but gives you an idea of how all can be simple. It is based on Hibernate and this means you have to download and extract a number of Jars to be put in your project (all explained in detail), but this is a one-time operation. Now you could use EclipseLink (Toplink-based): just extract two jars (eclipselink.jar and javax.persistence_xx.jar) and you are done.
|
|
|
Message #280955
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
ORM and DBMS could be friends
Hi Robert,
>> Which is why the Versant Object Database implements JDO and JPA ( in alpha ).
That sounds interesting. My crime is that I have written an "interesting" ORM called Ebean (its JPA like but without the issues) and based on that work I'm prepared to make a couple of predictions.
1. RDBMS's (with MVC architecture and a few tweaks) will start looking very similar to an OODBMS and vice versa (*there is a caveat)
2. DBMS Vendors and ORM Vendors will increasingly integrate their products.
The caveat to 1 is that RDBMS vendors may not be interested in looking like an OODBMS and specifically will not enhance SQL for better/more performant object graph navigation/queries.
On the other hand, looking at Oracle (and Postgres) right now with exposed ROWID and MVC timestamp there is a real ability to navigate object graphs in a highly performant OODBMS like fashion (physical rowid, background fetching with read consistency etc). IMO you need access to the physical ROWID and MVC timestamp to make this work (can't see non-MVC RDBMS doing this I'm afraid).
IMO the driver for more integration/cooperation between ORM and DBMS is "Autofetch" - aka ORM automatic query tuning.
Example Introduction to Autofetch support in Ebean:
http://www.avaje.org/ebean/introquery_autofetch.html
(In case you don't already know) what "Autofetch" does is automatically tune the ORM query based on the application usage of that query. So it optimises the query (joins, properties to fetch etc) based on profiling information that is gathered. This profiling information also tells you if the application wants "first rows" is paging through the data all using the entire object graph.
Now with an RDBMS and SQL there are some things you can do to optimise lazy loading etc. If you have a database which exposes its MVC timestamp you can do more things (more background fetching in a read consistent fashion). If its an OODBMS with a more object graph orientated query language you could do even more etc etc.
This can mostly be done transparently for the developer which is really nice - optimised queries with *LESS* work (perhaps not for 3 tier situation).
Also, one of the major issues I have with JPA / JPQL is the lack of partial object support. IMO this is a major blunder and they are going to have trouble enhancing JPQL to have proper partial object support.
I'm pretty ignorant of VQL. I've had a quick look ...
So the questions I have are:
- Is there a introduction to VQL for SQL developers?
- Does Versant use a MVC like architecture?
- If so does it expose its MVC timestamp (like Oracle does)?
- Do you see advantages of using VQL over SQL for ORM object graph construction/navigation?
Thanks, Rob.
|
|
|
Message #280958
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Problem with ODBMS
Sometimes when you need real performance in production you have to consider non-relational technologies.
By that time transparent persistence usually is also out of question.
By the way, even when you consider raw analytics, some former RDBMS gurus now claim that relational model is not so suitable, see for instance Stonebraker's Vertica.
Sure. We know that for ages, that's why we have OLAP, for example. 'Column databases' are just another optimizations of RDBMSes.
|
|
|
Message #280967
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Future of RDBM Systems and Persistency
I think huge i-can-handle-everything RDBMS systems might slowly disappear or change their merely table nature in future.
Considering the two diverse nature of current enterprise systems which are either highly transactional (XTP) or data-intensive its obvious that single relational solution will not continue to fit well for both.
What (will) see is the rise of optimal solutions for these two groups on needs. For the XTP systems will have IMDG solutions such as Coherence and WXS backed by simple and optimize packages such as Berkley-DB, db4o, or even MySQL. The rise of IMDG leads to rise of ORM/JPA since their object/filter based view best fits grids.
For data-intensive systems, maybe we face the rise of cubic systems influenced by Google's BigTable (such as hypertable) and content repositories (e.g. JCR).
Maybe that is the reason behind both Oracle and Sun's decision to invest on Coherence and MySQL and see IBM hardly working on its WebSphere eXtreme Scale while most on these vendors have their own classic and well known RDBMS systems.
Amin Abbaspour
|
|
|
Message #280968
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SUGGESTION: Direct Persistence Layer in Berkeley Database
By the way there is nothing in JDO today preventing from implementing it for non-relational databases. The same could apply to JPA, even if this one has been more focused on ORM than JDO.
Hi Eric,
So, true. Which is why the Versant Object Database implements JDO and JPA ( in alpha ).
Wasn't Versant OpenAccess (once JDOGenie) discontinued and moved to Vanatec ?
Is there still a JDO layer on top of Versant DB ?
Guido
|
|
|
Message #280969
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Criticism of Java Persistence Frameworks
About the listed "issues".
1. I think that is better leave silver bullets to smoke-seller. For me, it is enough to have some tools that allows me to not allocate 20-30% of development time to DB interface.
2. For some unknown reason
3. I guess the author means the mapping metadata. Maybe he prefers the annotation hell, where you put table and column names into java source. Wonderful!!
4. Poor ORM tools do that. Change the tool.
5. See point 1. I prefer to write a path expression in 99% of cases and a direct SQL in the remaining 1 instead of getting crazy with 2 pages of SQL just put 3 tables in join. But it is a matter of taste.
6. Agree
7. Yes, it is a hard work, even with plain JDBC
8. What a persistent object is it's up to the developer. If it is weak, maybe it is because he/she is not smart enough.
9. At least with JDO you have optimistic transaction. A totally unknown concept in plain JDBC world.
10. How many kilos ?
11. I would say without enough options.
12. Which one ? pm.makePersistent(o) is much simpler than JDBC I think.
13. One sample problem, please.
14. I suggest Scott Ambler writings on the same topic.
15. See point 8. with much more emphasis
16. Too cryptic for me
17. Your clustering vision is ?
18. Not very clear what is the issue here. DB events might only deal with table, rows and columns. ORM deal with classes.
19. Isn't that easy. You easily come to deal with object ownership. You need to integrate with authentication frameworks to get current Principal. Map principals to DB subjects....Hmm, there is a hole, but is it not ORM specific. Even POJOs suffer of the same problem.
20. ??????
21. Code generation ? In point 8. the issue was exactly that.
22. Problem of specific implementation not of the technology.
23. That is ?
As it often happens, own lack of knowledge is turned into framework pitfalls.
Guido
|
|
|
Message #280970
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java should learn from LINQ
I don't agree with "Object Query Languages are a wrong path".
If you take a look at .NET, you can see a strong object query language evolving: LINQ
I believe that Java would benefit a lot from a similar strong standard for object querying, one that would really make databases interchangeable.
What I don't like about most posts on persistence here: Authors don't imagine the wide range of application usecases. On small devices an object database can make a lot of sense, if it's more direct persistence approach brings bigtime benefits for performance.
...plus you get all the development-time advantages of using an object database:
type-safety, refactorings, single schema, no mapping files, far less code, simplicity, ease of use
--
Carl Rosenberger
db4o - database for objects
|
|
|
Message #280977
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java should learn from LINQ
You're absolutely right Carl.
List of LINQ for Java projects (from my blog):
* LiquidForm: http://code.google.com/p/liquidform/
* JaQu from the H2 database.
* db4o is working on some kind of LINQ equivalent I think.
* JEQUEL.
* Quaere.
* LINQ for Java (Google Group).
* Query DSL.
Carl: correct me if I'm wrong on the db4o initiative.
Most people just know the kind of projects they are working on. You have a wide range of databases today from mainframes to embedded devices. Most of the existing data stores today don't have a relational SQL interface.
Persistence is definitely not limited to ORM.
I think the market is starting to understand there are different database technologies, and you should not use RDBMS everywhere.
But don't get me wrong. Relational is still the prevalent model and is here to stay. The Cloud databases and Database-as-a-Service will eventually find their markets (niches?), and maybe ODBMS too, but SQL will remain here for a long time, as it has proven to be the right solution in many data management cases. The new thing is that with SOA at one side, and mobile applications at the other side, there is now some room for alternate storage technologies.
With the raise of multiple storage technologies, distributed services, service layers in front of databases, data dispersion, and multiple client technologies (PDA, POJOs, POCOs, SCA, BPEL, workflows, rules engines, SilverLight, Ajax, SDO...) the need for a good data integration and mediation layer will become much more than necessary.
- Eric Samson.
http://www.dataservices-connection.com/
|
|
|
Message #280978
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ORM
ORM = solution in search of a problem. Hibernate is a waste of time and resources.
I wouldn't go that far to criticize hibernate or any other ORM tool, but in reality I almost agree with you. I haven't seen any real world project, where you can achieve 100% with any ORM tools, there are many occasions where you have to roll over your sleeves and right plain JDBC code, or may be even stored procedures. At the end you have a code base that is Mombo-Jumbo of every thing. The only reason you see these ORM tool so popular is first because of the IT marketing (Good for me, bad for my clients, but why the hell I care if they buy every thing I feed them:-)), and second because at the end we all work for money and developers thinks one more framework will look good on their resume at least to find a new job. Alas what a shallow world we developers live in.
RJ
Speak for yourself. I've been using Hibernate for projects ranging from simple web apps to web-based products for *years*, right hear in the real world.
What a shallow developer who thinks he's seen it all when he's seen very little.
What a shallow developer who thinks he has any idea of what I've seen.
|
|
|
Message #280987
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ORM
What a shallow developer who thinks he has any idea of what I've seen.
I don't want to get involved in a fight over ORM but I started a library for working with databases in a fundamentally different way than ORM. You could build ORM on top of it, I suppose, but it's not really my goal. If you are interested in contributing or trying it out, I can give you some more details. It's kind of stalled as I've stretched myself too thin. It's also a problem area with a lot of projects so I'm not sure it's worth putting a lot of time into.
|
|
|
Message #280988
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ORM
ORM = solution in search of a problem. Hibernate is a waste of time and resources.
I wouldn't go that far to criticize hibernate or any other ORM tool, but in reality I almost agree with you. I haven't seen any real world project, where you can achieve 100% with any ORM tools, there are many occasions where you have to roll over your sleeves and right plain JDBC code, or may be even stored procedures. At the end you have a code base that is Mombo-Jumbo of every thing. The only reason you see these ORM tool so popular is first because of the IT marketing (Good for me, bad for my clients, but why the hell I care if they buy every thing I feed them:-)), and second because at the end we all work for money and developers thinks one more framework will look good on their resume at least to find a new job. Alas what a shallow world we developers live in.
RJ
Speak for yourself. I've been using Hibernate for projects ranging from simple web apps to web-based products for *years*, right hear in the real world.
What a shallow developer who thinks he's seen it all when he's seen very little.
What a shallow developer who thinks he has any idea of what I've seen.
I know you haven't seen everything, so to suggest that there aren't any real world projects that cannot use an ORM exclusively, then further suggests that the world of developers is shallow is pretty silly and most likely wrong.
Between HQL and simply passing strings to Hibernate, you can can bypass JDBC. And the use of Stored Procedures is supported by at least Hibernate and Toplink, so you still have 100% use.
Speak for yourself. Just because you haven't seen something in the real world, doesn't mean it isn't done everything day.
|
|
|
Message #280990
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The issue is architecture
A complete, working Java application can be created that stores all its data as POJOs in Collections. So simple 'Java persistance' *is* possible.
Anyone having problems extending this model into a database is just doing something wrong. Stop overthinking and expecting the database to do more than it should?
Rudimentary computer courses will explain how Java Collections/Iterators can be extended to work over Terrabytes of data, just grab a Java manual, read about the Collections API, all your problems are solved.
|
|
|
Message #280991
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SUGGESTION: Direct Persistence Layer in Berkeley Database
Oops missed a char somewhere in that one..
You can see in our latest
Press_Release today.
-Robert
Versant Corp
BTW: I forgot to congratulate both of you Robert and Carl.
Best regards
- Eric.
|
|
|
Message #280994
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Problem with ODBMS
Sometimes when you need real performance in production you have to consider non-relational technologies.
By that time transparent persistence usually is also out of question.
Not always. It depends on the kind of problems you want to address. A good persistence layer + an efficient storage layer can still be much more efficient than relational.
But you added "usually", so you know it and you are covered :-)
|
|
|
Message #280995
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Problem with ODBMS
Sometimes when you need real performance in production you have to consider non-relational technologies.
By that time transparent persistence usually is also out of question.
By the way, even when you consider raw analytics, some former RDBMS gurus now claim that relational model is not so suitable, see for instance Stonebraker's Vertica.
Sure. We know that for ages, that's why we have OLAP, for example. 'Column databases' are just another optimizations of RDBMSes.
We know it, however some RDBMS supporters are still trying to impose the "RDBMS everywhere" model, even when it does not make sense.
What is new, is that even RDBMS gurus are now saying the opposite
|
|
|
Message #280998
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ORM and DBMS could be friends
....predictions.
1. RDBMS's (with MVC architecture and a few tweaks) will start looking very similar to an OODBMS and vice versa (*there is a caveat)
2. DBMS Vendors and ORM Vendors will increasingly integrate their products.
Yes, I would agree, movment towards a "simple enough" API is what will/is happening. However, it's what's on the inside that will count. As tech moves in this direction and the transactional storage is abstracted, it will be about total cost of ownership ... kilo watts.
You can make an RDB look like an ODB, actually people do it all the time, because for some applications, like in the social networking space, they must, in order to get scalability - use application managed identity to avoid JOINs. But ... then you lose powerful query, closure, etc and basically end up with a transactional file system.
IMO you need access to the physical ROWID and MVC timestamp to make this work
What you have to be careful about here is the long term impact to your performance. Fragmentation is extremely hard to deal with if you tie yourself to physical ids. In order to defrag... you have to find every reference in the system and patch it. Systems need one level of indirection to avoid these real world issues.....that is if your trying to run 5-9's with only 2 minutes down time a year.
...what "Autofetch" does is automatically tune the ORM query based on the application usage of that query.
This is good stuff ;-)
I'm pretty ignorant of VQL. I've had a quick look ...
So the questions I have are:
- Is there a introduction to VQL for SQL developers?
- Does Versant use a MVC like architecture?
- If so does it expose its MVC timestamp (like Oracle does)?
- Do you see advantages of using VQL over SQL for ORM object graph construction/navigation?
Thanks, Rob.
1) VQL for SQLers.. not really, just the manual. it's really quite similar so nobody has a hard time understanding it. It's just that Tables=Classes and Columns=Attributes. All the rest is very readable.. groupBy, Having, Set operators, etc. Only thing a bit different is that a JOIN is expressed as a model navigation path using a -> operator.
2) MVC - timestamp....We use a different kind of version control system, model based, when you actually need that for your application. It is not backed into all database operations.
3) SQL -vs- VQL.... I do not see any real advantages when it comes to dealing with object graphs. Mind you, the plethora tools available which understand SQL make things easier once you step outside of your oo models. For Versant, we enable this same kind of access (Crystal Reports, etc ) using and ODBC/JDBC bridge type of driver. So, we can do it, but it's just slower than our native VQL.
Cheers,
-Robert
Versant Corp
|
|
|
Message #281001
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SUGGESTION: Direct Persistence Layer in Berkeley Database
Wasn't Versant OpenAccess (once JDOGenie) discontinued and moved to Vanatec ?
Is there still a JDO layer on top of Versant DB ?
Guido
Yes, there is a JDO layer. We simply spun out the ORM stuff because what was important was the approach "simple enough" API and that was accomplished. Now most people in the Java world use the API that has existed in Versant since the mid 90's. BUT - we do it without any mapping!
Right tool for the job,
-Robert
Versant Corp
|
|
|
Message #281002
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ORM and DBMS could be friends
1) VQL for SQLers..[snip]
2) MVC - timestamp....[snip]
3) SQL -vs- VQL.... [snip]
Wow people really go through all this effort?
CRUD: Create, Request, Update, Delete
Create:
map.put("key", bean);
Request:
bean = map.get("key");
Update:
bean.setPrice("10 zillion dollars");
map.put("key", bean);
Delete:
map.remove("key");
=========
Options:
- Do this with Hibernate? Save yourself some time.
- Derive your own hashmap, override and persist beans to something else, odb, xml, or even dot matrix printer that a carrier pigeon brings to lala land
- only use SQL if you need to do some kind of reporting.
KISS - when you start doing this:
SELECT OMGWTF.a ACK.b UGG.c from IRLLY, NEEDTO, RETHNkLIFE, UNION (SELECT FOOBAR JOINED with UGLYJUNK.xyz) [snip more crosseyed stuff]
You're doing something wrong.
|
|
|
Message #281006
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The issue is architecture - Java is excellent platform
I agree with Sal F.
Java now has EJB3, which has a lot of wonderful tools to build scalable world class applications, including Objects mapped to database via ORM included within Session Beans to create SOA applications.
Software languages and tools evolves through time, and as I am a developer who started in 1982 I can say that Java creators are doing wonderful.
People should study more Java SE and Java EE to unlock its potencial.
|
|
|
Message #281025
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ORM and DBMS could be friends
Wow people really go through all this effort?
CRUD: Create, Request, Update, Delete
Create:
map.put("key", bean);
Request:
bean = map.get("key");
Update:
bean.setPrice("10 zillion dollars");
map.put("key", bean);
Delete:
map.remove("key");
Crazy isn't it ...
I much prefer:
bean = new Bean("me");
bowl.getBean();
bean.eat();
bowl.empty(); .... or if you prefer crapBean(); :-)
And.... save yourself some time, don't use Hibernate, don't bother with the mapping, use an OODB. Well, OK maybe for a model like the above it's fine, but not if your building a social network, bioInformatic, network management, etc.
Right tool for the job,
-Robert
Versant Corp
|
|
|
Message #281024
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Make it simple, but not simpler
As Einstein said, "Make everything as simple as possible, but not simpler.".
There will come a time when I only have to speak out my requirements to a Computer and it will write the program all by itself!
|
|
|
Message #281027
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Make it simple, but not simpler
HA HAaaa !!
I have those same dreams. And one day, they will come true.
but for now ... no. Reality is your need things to manage the scale and concurrency that go beyond the simple stuff... cursors, explicit locking, distribution, etc.
Sad reality is those things are never easy.
Cheers,
-Robert
Versant Corp
|
|
|
Message #281029
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Make it simple, but not simpler
HA HAaaa !!
I have those same dreams. And one day, they will come true.
but for now ... no. Reality is your need things to manage the scale and concurrency that go beyond the simple stuff... cursors, explicit locking, distribution, etc.
Sad reality is those things are never easy.
Cheers,
-Robert
cursors:
=======
Cursors = iterators
Iterator i = list.iterator()
while (i.hasNext())
((MyBean)i.next()).doSomething();
explicit locking:
=======
- all RDBMs's will ensure that data integrity is there if you use them properly (simple CRUD operations)
- if you need to 'lock' something critical, Java handles this for you too - use the 'synchronized' keyword where needed on some serverside object. Multiple servers? Make a service
distribution:
=======
Another KISS issue. All real RDBMSs including MySQL, a free one, support distribution. If you have a simple CRUD app it will scale with no issue.
Keep in mind with using proprietary systems, that your app may not be able to run in environments like Windows Azure, Amazons EC2, or even Google App Engine, cloud computing systems that are the next generation of applications, and their database systems really only support simple CRUD applications/architectures as the industry has proven (Google with Gmail for example) that this is the best approach.
|
|
|
Message #281034
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ORM and DBMS could be friends
I much prefer:
bean = new Bean("me");
bowl.getBean();
bean.eat();
bowl.empty(); .... or if you prefer crapBean(); :-)
And.... save yourself some time, don't use Hibernate, don't bother with the mapping, use an OODB. Well, OK maybe for a model like the above it's fine, but not if your building a social network, bioInformatic, network management, etc.
Right tool for the job,
-Robert
I disagree, what if you want to use 'Bean' and all its operations without hitting a DB at all? Javabeans should be kept simple.
The same reason Java architects didn't include templates as in C++ despite make the language after C++ was around for years - certain things should be explicit as it actually makes things simpler:
bean = map.get("key") makes it very obvious that the POJO is being retrieved from some sort of storage, yet is very simple. 'new' should be used for its intention: create a POJO, no DB interaction intended.
Of course: its just my opinion though, really I support any simplification of persistance... so what you suggested is much more suitable than a lot of the crap that some vendors try to sell to developers, that really just make their lives a lot more complex!
|
|
|
Message #281059
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ORM and DBMS could be friends
I much prefer:
bean = new Bean("me");
bowl.getBean();
bean.eat();
bowl.empty(); .... or if you prefer crapBean(); :-)
And.... save yourself some time, don't use Hibernate, don't bother with the mapping, use an OODB. Well, OK maybe for a model like the above it's fine, but not if your building a social network, bioInformatic, network management, etc.
Right tool for the job,
-Robert
I disagree, what if you want to use 'Bean' and all its operations without hitting a DB at all? Javabeans should be kept simple.
The same reason Java architects didn't include templates as in C++ despite make the language after C++ was around for years - certain things should be explicit as it actually makes things simpler:
bean = map.get("key") makes it very obvious that the POJO is being retrieved from some sort of storage, yet is very simple. 'new' should be used for its intention: create a POJO, no DB interaction intended.
Of course: its just my opinion though, really I support any simplification of persistance... so what you suggested is much more suitable than a lot of the crap that some vendors try to sell to developers, that really just make their lives a lot more complex!
Well, with an ODBMS that supports persistence through reachability, you don't hit the database until the "bean" has been put into a persistent container. Thus you can create and manipulate all the transient objects that you want without involving the database.
Once the object is inserted into the database, it becomes a shared object, and is under the control of the transaction manager.
A good ODBMS will allow for dirty reads, i.e. no locks. If you want to access an object without a read lock, you can do so. Optimistic locking is also available, which is a lot more powerful in my opinion. This will have the same affect as your model in which you explicitly copy the object from the database, and manipulate the copy until you're ready to reinsert it back, i.e. update the object.
Mark
|
|
|
Message #281065
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ORM and DBMS could be friends
Well, with an ODBMS that supports persistence through reachability, you don't hit the database until the "bean" has been put into a persistent container. Thus you can create and manipulate all the transient objects that you want without involving the database.
Once the object is inserted into the database, it becomes a shared object, and is under the control of the transaction manager.
A good ODBMS will allow for dirty reads, i.e. no locks. If you want to access an object without a read lock, you can do so. Optimistic locking is also available, which is a lot more powerful in my opinion. This will have the same affect as your model in which you explicitly copy the object from the database, and manipulate the copy until you're ready to reinsert it back, i.e. update the object.
Mark
The problems with this type of logic - it *aims* to make things simpler, but in essence make things more complex.
This is the point of the whole thread really, developers getting confused as to why theres all this 'junk' out there, and that there must be an easier way.
For this kind of transparent persistance in Java, you have to resort to all kinds of bytecode injection, littering your code with strange tags, or wierd XML mappings.
For persistance Java gives Collections, you use standard OOP practices to configure how the persistance behaves. Deriving/Inheriting from the appropriate places.
Java Reflection gives all the power needed to introspect beans and serialize them properly... as long as we keep things simple.
As soon as you get yourself into bytecode injection, XML mappings, or freaky annotations you start crawling into this ugly hole that moves far away from nice, clean OOP and moves into a very ugly place.
It can't really get simpler than:
map.put("key", bean)
without getting much uglier.
|
|
|
Message #281086
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Needs some challenge to implement java applications
Java persistence frameworks are becoming mature and I appreciate efforts to make it better and having more feature to solve different problems. Comparing to EJB, framework like Hibernate brought much more flexibility and power and we expect better design or solution in future. If development needs some thought to challenge different and complex issues, that is be nature of the job! Having some comments like “Don’t throw SQL away, it is not enemy” or “Object Query Languages are a wrong path” remind me the argument (sometimes) we have with database developers to use database feature like stored procedure and putting business logic at database level or use java framework.
There is no obligation to use POJO and OQL(HQL,…) for every single or small query. you can use native sql or even stored procedure for many purposes.
For “Object-Relational Impedance Mismatch” is not solved”, it is true and I am not expecting to be solved, that’s why we use ORM, but I don’t get what is your point in that paragraph.
|
|
|
Message #281088
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SUGGESTION: Direct Persistence Layer in Berkeley Database
In the end, I found myself questioning the need for RDBMS on the vast majority of my projects
And with the arrival of the buzz around clouds and such, added to that how cheap the memory is, there is actually a whole movement to removing the RDBMS from the stacks...
Ever heard of GigaSpaces?
|
|
|
Message #281089
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Needs some challenge to implement java applications
Java persistence frameworks are becoming mature and I appreciate efforts to make it better and having more feature to solve different problems. Comparing to EJB, framework like Hibernate brought much more flexibility and power and we expect better design or solution in future. If development needs some thought to challenge different and complex issues, that is be nature of the job! Having some comments like “Don’t throw SQL away, it is not enemy” or “Object Query Languages are a wrong path” remind me the argument (sometimes) we have with database developers to use database feature like stored procedure and putting business logic at database level or use java framework.
There is no obligation to use POJO and OQL(HQL,…) for every single or small query. you can use native sql or even stored procedure for many purposes.
For “Object-Relational Impedance Mismatch” is not solved”, it is true and I am not expecting to be solved, that’s why we use ORM, but I don’t get what is your point in that paragraph.
A lot of the issues are stemming from the fact that persistance can really only be 'so simple'.
A developer at work is creating large-scale data centric applications with his own homerolled taglib like this:
<myDataView>
<primaryDataCol Name="Id" />
<textDataCol Name="Title" />
<textDataCol Name="Description" />
<textDataCol Name="Price" />
</myDataView>
In turn generating HTML/web applications that are CRUD style apps, and they've been scaling to terrabytes without issue. (The above code is uploaded as a JSP, you have searching, sorting, edit/update/etc. and even some reporting all built in using the taglib.) There are a lot of higher-level Java frameworks that work like this also.
Several lines of code for a data centric application (not just the persistance logic... but the UI also) shows that the true savings comes not from the underlying data layer at all, but just good, old fashioned object oriented programming used *everywhere*.
A major fundamental problem with ORM and other Object style as they encourage putting Business data structures in as code - this is fundamentally wrong. Code is supposed to encapsulate procedural logic... thousands of Javabeans that do nothing but act as a declarative representation of some tables in a database are a waste of time, no matter how they are being persisted.
If a new property comes up for an inventory application, say a new type of 'SKU code' you shouldnt have to update procedural code to allow this change, but rather a change to some application configuration file (or other data source) would be the proper thing to do.
Personally I'm not using a taglib as described above - even these are in my opinion meant for more procedural things, but other DSLs (but that's a whole separate discussion, anyway...)
|
|
|
Message #281128
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Needs some challenge to implement java applications
That could be fine for pure data management applications (basic CRUD + forms) with no business logic.
But sometimes (often? / always?) you need a business model, not every applications are just a set of input/display forms.
|
|
|
Message #281168
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Needs some challenge to implement java applications
A major fundamental problem with ORM and other Object style as they encourage putting Business data structures in as code - this is fundamentally wrong. Code is supposed to encapsulate procedural logic... thousands of Javabeans that do nothing but act as a declarative representation of some tables in a database are a waste of time, no matter how they are being persisted.
Right, but it is not a major fundamental problem with ORM.
It is a major fundamental problem with architects/designers/developers employed for the wrong job.
Conceiving software is not for all.
If a new property comes up for an inventory application, say a new type of 'SKU code' you shouldnt have to update procedural code to allow this change, but rather a change to some application configuration file (or other data source) would be the proper thing to do.
Couldn't disagree more.
If a new type of SKU code is needed, then it means that processing of this new property must be done somewhere.
And anyway, in the extreme case where this property must be only shown to the user, then we are talking about the correct design for dynamic properties (see Martin Fowler patterns).
Again, conceiving software is not for all (not speaking about you, I know a lot of people that would spend better time in agriculture).
Guido
Guido
|
|
|
Message #281188
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Stop Hibernating, jIncarnate!
“Isn’t there any other solution to persistence problem simpler and more powerful?” I recommend you to take a look at jIncarnate.
This product compiles JDBC database and query metadata to Java interfaces and classes. It supports generics, has criteria API and generates enumerations for table columns. As a result, there is less code to write, and there is no embedded {S|H}QL in a Java application which uses jIncarnate-generated classes to access database. If database or one of SQL statements changes in an incompatible way, then Java code won't compile manifesting problem at build time instead of runtime.
One caveat is that the tool relies on metadata provided by JDBC driver. Pure Java databases do a good job here, but some older databases implement metadata API only partially. It leads to the need to provide additional configuration data. A workaround is to use HSQLDB (bundled with the tool) to parse DDL and DML scripts to produce good quality metadata.
Another point worth mentioning is that though the tool supports mappings, i.e. one Java method can be mapped to different tables and different columns, it is not what it is about. Its primary purpose to reduce amount of hand-crafted code and make data access more robust.
I noticed that ORM tools pay a lot of attention to the M. It is probably important for some vendor products, which have to work with different databases. My experience shows that in applications developed in enterprise IT shops a given data access module works with only one database. As a result mapping layer causes development and runtime overhead.
|
|
|
Message #281189
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ORM and DBMS could be friends
For persistance Java gives Collections, you use standard OOP practices to configure how the persistance behaves.
Something tells me you never had to deal with an iterator of a billion or several billion things. The notion that you can simply use a collection is an over simplificaton.
Thats the thing, there is theory and then there is practice. Even though a great deal of the persistence issues can be simplified, some elements of it can't .... at least not with todays' technology.
A cursor != iterator
Everything is easy when it's 10's of gigs and 100s of people. Nothing is easy when it's 10's of 100's of gigs and 100s of 1000s of people.
I personally like map persistence. I like ORM persistence, I like flat files, straight jdbc, odbms, etc. when the task and hand calls for one over the other.
You need to ask the right questions to discover what is the most appropriate choice. I suggest that when it's millions/billions of things, complex relationships, increasing amounts of data, lots of concurrent users.... especially in a transactional context, you might wanna take a look at an oodb instead of a map.
Right tool for the job,
-Robert
Versant Corp
|
|
|
Message #281194
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ORM and DBMS could be friends
For persistance Java gives Collections, you use standard OOP practices to configure how the persistance behaves.
Something tells me you never had to deal with an iterator of a billion or several billion things. The notion that you can simply use a collection is an over simplificaton.
Even though a great deal of the persistence issues can be simplified, some elements of it can't .... at least not with todays' technology.
A cursor != iterator
JDBC's cursoring implementation *is* identical to Java's Collection API iterator pattern. In fact you could wrap it 1-for-1. Not sure why you don't think it wouldn't work, its definately not a limitation in Java.
JDBC example:
ResultSet rs = ((MyRDBCallableStatement)stmt).getCursor(2);
while (rs.next())
[snip]
looks like an iterator right?
Everything is easy when it's 10's of gigs and 100s of people. Nothing is easy when it's 10's of 100's of gigs and 100s of 1000s of people.
My current employer is the largest J2EE infrastructure in the world currently (a fortune 100 company). Not doing too great in the current economy but, trust me I have to see things scale in the scariest ways.
I suggest that when it's millions/billions of things, complex relationships, increasing amounts of data, lots of concurrent users.... especially in a transactional context, you might wanna take a look at an oodb instead of a map.
I would respect you have good reason to say this, but lets take some concrete real world examples:
Google's AppEngine contains BigTable which is designed *specifically* to scale, and it is not an OODB. Here is Google's quote:
"BigTable is designed to scale into the petabyte range across "hundreds or thousands of machines, and to make it easy to add more machines [to] the system and automatically start taking advantage of those resources without any reconfiguration"
If you take a look at the BigTable API, it really just supports simple CRUD operations.
To scale well, and really grow things really just need to be kept simple. BigTable for example, really just acts like a glorified Map. Its a lot to say for simplicity.
|
|
|
Message #281195
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Needs some challenge to implement java applications
If a new property comes up for an inventory application, say a new type of 'SKU code' you shouldnt have to update procedural code to allow this change, but rather a change to some application configuration file (or other data source) would be the proper thing to do.
Couldn't disagree more.
If a new type of SKU code is needed, then it means that processing of this new property must be done somewhere.
And anyway, in the extreme case where this property must be only shown to the user, then we are talking about the correct design for dynamic properties
What else are you going to do with a SKU code other than:
1) display it along with other properties
2) allow to 'search' for items via this property
3) possibly some reporting containing references to the property
Unless you work for a manufacturer of barcode scanners, that is what most people would do with it. Just like all the other run-of-the mill properties that are in databases, typically. No need for a 'getter' or 'setter' since you're not using the property in any procedural code.
(its not a bad thing necessarily... we as developers just need to capitalize on the redundancies, stop writing hundreds of useless beans, and just simplify architectures.)
Using an OODB or complex SQL-clone-hack will not be the solution as developers often think. The simplification comes from overall application architecture, and rethinking ways to write your app that isn't so database-centric.
|
|
|
Message #281196
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ORM and DBMS could be friends
Google's AppEngine contains BigTable which is designed *specifically* to scale, and it is not an OODB.
I want to make clear, I am not saying OODB is the be all end all answer to persistence.
Of course, there are other scalable solutions. But... Google does not use a Java collection. That's my point. You need to ask the right questions to decide what you need.
Google does not have to worry about logically consistent update across complex relationships. It does not care if things are current. it just needs to find things fast in a vast quantity of information ( of course I am talking search which encompasses some of the other criteria I mentioned earlier ).... and not with 100% correctness, but with some hint of relevance.
It is very different from something that must get at a bunch of related information, dependent on each other in some fashion, ensure that everything is locked *together* in a way that no other thread can modify any element of that bunch, allow changes to part of that bunch, ensure that all changes are stored as an isolated unit of work all or nothing. Your not going to do that with BigTable, you would only be able to do that by writing a sophisticated level of abstraction over the storage structure. You will have to write something similar to what you already get from a dbms....rdb, odb or otherwise.
But why care, Google just does not have to do that .... and BigTable/MapReduce is not intended to solve that kind of problem.
I'm sure BigTable works for some particular problem, but I would bet that the code you have to write to manage a model with 10 levels of inheritance, recursive relationships, collections of collections of collections, etc. would be extreme in relation to what is required with the typical oodb.... not to mention handling true logical consistency issues.
The idea of just adding machines to get scale is not new. 1 example of many, Versant has a system running helicopter simulators for Evans and Sutherland ( Military M80 stuff ) built in the 90's that uses and array of 600 physical databases. Versant has the notion of a virtual database instance where the application sees a logically named database that is composed of many physically distributed nodes. Queries, transactional updates, etc are done as parallel operations across the cluster of physical nodes.
All that being said, if I have a large data relevance problem to solve, or just a large simple data storage and retrieval problem, maybe I should look at BigTable. Another good tool for some jobs.
I say ( as a repeat of many smarter than I )....Knowledge is power, to dismiss what you do not know or understand is ignorance. We are all better off with less ignorance. Sharpen the saw, learn something new, deliberately decide.
Right tool for the job,
-Robert
Versant Corp
|
|
|
Message #281200
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Needs some challenge to implement java applications
What else are you going to do with a SKU code other than:
1) display it along with other properties
2) allow to 'search' for items via this property
3) possibly some reporting containing references to the property
Unless you work for a manufacturer of barcode scanners, that is what most people would do with it. Just like all the other run-of-the mill properties that are in databases, typically. No need for a 'getter' or 'setter' since you're not using the property in any procedural code.
(its not a bad thing necessarily... we as developers just need to capitalize on the redundancies, stop writing hundreds of useless beans, and just simplify architectures.)
Using an OODB or complex SQL-clone-hack will not be the solution as developers often think. The simplification comes from overall application architecture, and rethinking ways to write your app that isn't so database-centric.
And so ?
It's a problem of bad design having to change a bean to make room for the new property. It is not the ORM technology to blame.
Obviously (I didn't mention earlier) the choice it is always a matter of balance between money, app lifetime, available skills and maybe other tons of factors.
Guido
Guido
|
|
|
Message #281208
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A few thoughts...
I agree to some extent about point 12, however I do not agree at all with the code in his example, specifically the dbEmployee.dbSave() line. Objects should be POJOs with only specific knowledge of their domain, they should be usable outside of the persistence framework and not have to extend persistence classes or know anything about persistence.
As far as mapping, I have a real problem with annotation based mapping, at least when your project is not a one off and is intended for use with multiple databases. Annotation is basically putting persistence knowledge into the object. I prefer the ability to configure this at installation time.
|
|
|
Message #281308
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Needs some challenge to implement java applications
And so ?
It's a problem of bad design having to change a bean to make room for the new property. It is not the ORM technology to blame.
I'm not blaming ORM technology really - but the ORM 'mentality'. You're planning to use procedural code objects, to represent the data structure of an application.
There are situations where you need to accomplish some kind of procedural logic - tightly mixed with database persistance, but this situation is in my opinion a 'last resort' scenario. 99% of applications are doing run-of-the mill things like listing things out of a table, allowing users to do some CRUD operations with possibly some workflow and security.
Obviously (I didn't mention earlier) the choice it is always a matter of balance between money, app lifetime, available skills and maybe other tons of factors.
Guido
Guido
I agree!! And partially the thread is in search of more efficient ways to do things.
My opinion:
1 - Start writing applications using a higher-level architecture. Assemble your application out re-usable components (high level compoenents!) that encapsulate UI, as well as database logic
2 - when your library fails to solve a particular business need, *then* fall back to adding new components, some of which may need to interact with a database
3 - In creating data-centric components use the simplest option available to you. My opinion - use a solution that keeps you in 'pure' Java. But still allows you the option to control how your data is persisted later
4 - Stop at 3 if you're persisting to a Relational database, obviously your work is done since 90% of the time this is where persistance ends. However if you have more needs - then your persistance API should allow to serialize elsewhere (XML? Filesystem? Another kind of proprietary datastore?
===
If you take this approach, you're always doing the simplest thing for the full development cycle. The majority of the time you'll *never* have to make a persistant bean or write a single line of SQL.
And you don't have to tie yourself to some proprietary, invasive, bytecode-injection type of framework that is, in the end (eventually you hit step #4 above) getting you screwed.
(I'm sure frameworks are going to come out that enforce the KISS principles, but for now we have to force ourselves to take the architecture decisions consciously)
|
|
|
Message #281330
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ORM and DBMS could be friends
Google's AppEngine contains BigTable which is designed *specifically* to scale, and it is not an OODB.
I want to make clear, I am not saying OODB is the be all end all answer to persistence.
Of course, there are other scalable solutions. But... Google does not use a Java collection.
Well, its Python currently - Java support is coming later apparently, but you see my point. Language regardless they are using the same CRUD pattern that you see when using a typical Hashmap.
(I only cited the example because you asserted that the principle can't scale to 'billions' of records, and BigTable is an example of something that is meant to go way beyond that)
That's my point. You need to ask the right questions to decide what you need.
Google does not have to worry about logically consistent update across complex relationships.
Complexity arising from the need to ensure consistency across complex relationships, is complexity derived simply because of the fact you're dealing with complex relationships! Not because of a choice of using a Datastore that supports simple CRUD operations.
A lot of 'complex' relationships can be expressed and dealt with without creating a single Javabean at all, but if you're stuck in the ORM mentality... its your only option.
Of course, eventually the need arises to have to interact directly to a datastore from procedural code... but if you're doing proper OOP, this situation should be few and far between.
Now for my point:
When you *do* need to interact directly with persistant storage, then chances are you're already working with Java collections, this is after all, the only way to really build complex relations in Java, dynamically.
So the logical extension is to extend collections to persist beans.
(see for the majority of cases you never need to touch a line of SQL, or do any ugly bytecode injection, or deal with proprietary persistance frameworks... if people just follow Good Architecture Principles)
It does not care if things are current. it just needs to find things fast in a vast quantity of information ( of course I am talking search which encompasses some of the other criteria I mentioned earlier ).... and not with 100% correctness, but with some hint of relevance.
It is very different from something that must get at a bunch of related information, dependent on each other in some fashion, ensure that everything is locked *together* in a way that no other thread can modify any element of that bunch, allow changes to part of that bunch, ensure that all changes are stored as an isolated unit of work all or nothing. Your not going to do that with BigTable, you would only be able to do that by writing a sophisticated level of abstraction over the storage structure. You will have to write something similar to what you already get from a dbms....rdb, odb or otherwise.
Transactional coherence has to extend far beyond your DBMS. If you're creating a professional-grade enterprise quality application, then you need to ensure transactional coherence is there over much more than *just* the DBMS.
This is why most of the J2EE frameworks deal with that at the 'Java' layer. Depending on the DBMS for this isn't a good approach.
And if you *did* depend on the DBMS to control transactional coherence what happens if you want to switch to another DBMS vendor? Or you need to serialize to say, a web service instead of a DBMS at all? You're screwed.
But why care, Google just does not have to do that .... and BigTable/MapReduce is not intended to solve that kind of problem.
I'm sure BigTable works for some particular problem, but I would bet that the code you have to write to manage a model with 10 levels of inheritance, recursive relationships, collections of collections of collections, etc. would be extreme in relation to what is required with the typical oodb.... not to mention handling true logical consistency issues.
If you're using beans and collections to express 10 levels of inheritance you're already doing something wrong.
Again: Code = *procedural* logic. No need to use it to encapsulate business data. Unless you're *heavily* mixing procedural logic with persistance logic this approach is rarely necessary.
When you *DO* need to use collections - then its rare to need to extend beyond the collections API. Simple transactional awareness can be done with something like:
database.beginTransaction()
map.put("x", bean)
database.rollBack()
The idea of just adding machines to get scale is not new. 1 example of many, Versant has a system running helicopter simulators for Evans and Sutherland ( Military M80 stuff ) built in the 90's that uses and array of 600 physical databases. Versant has the notion of a virtual database instance where the application sees a logically named database that is composed of many physically distributed nodes. Queries, transactional updates, etc are done as parallel operations across the cluster of physical nodes.
All that being said, if I have a large data relevance problem to solve, or just a large simple data storage and retrieval problem, maybe I should look at BigTable. Another good tool for some jobs.
Adding machines to scale is not a new concept.
But people (other than the military) having access to these kinds of scalable systems for so cheap (as with the new Cloud Computing trends) is new.
I say ( as a repeat of many smarter than I )....Knowledge is power, to dismiss what you do not know or understand is ignorance. We are all better off with less ignorance. Sharpen the saw, learn something new, deliberately decide.
Right tool for the job,
-Robert
But if it requires genius to understand the reasons to use a persistance API something else is wrong ;-)
(which is the main point of the thread - why isn't Java persistance simpler?)
|
|
|
Message #281407
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Impossible problems are indeed very difficult to solve
There is an inherent level of complexity and difficulty in relational data definition and management. This is not an impossible problem to solve, but it is decidedly not for the average programmer.
The impossible problem arose when the business (data) applications were migrated from 4GL to a lower level 3GL language such as Java. It is a human resource and scaling issue: where to recruit an army of sophisticated programmers to do the task that was originally handled by 4GL (systems) written by (few) sophisticated programmers, and the (human resources) scaling problem addressed by hold-my-hands IDEs and scripting languages?
Test yourself:
1 - What precisely is the "Object Relational impedance mismatch". (Please do not discuss the symptoms; address the fundamental essence, and no hand waving, please.)
2 - What are the benefits of explicit architectural articulation of tiers in what are (effectively) client-server applications?
2b - If you rattled off a few benefits, please consider the word "explicit" as meaning: subject to significant input and modification by the "application" programmer.
3 - What are the benefits of crafting near redundant object models where entity relational models precisely capture a domain's data, in a world where the reality is firmly data-centric and data models outlive languages (to say nothing of object models written in those languages)?
3a - To what degree do you reuse your object models across applications in your enterprise? (User.setPassword() does not count ..)
3b - If you answered "very little" to 3a, the question posed is: what benefits do (have) you gain(/ed) by (the very tedious exercise of creating) the said object model?
4 - If you consider OODBs to be a panacea, please discuss how you address the 'new' (not so trivial) problems that arise with 'transparent' persistence of object graphs? (Identity, liveliness, graph depth, etc.)
4a - To wit: would we then see barely literate articles "criticizing" how "difficult" it is to address the "Object and ODB temporal mismatch"?
5 - Would you stop bitching ("criticism") if a few hard core programmers wrote a 4GL for the tiered architecture and your job was reduced to wiring (web) UIs in a design environment ala Delphi with a Java-lite scripting language, or would you consider that to be too boring and beneath you?
/R
|
|
|
Message #281408
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: fundamentally different library
If you are interested in contributing or trying it out, I can give you some more details.
Link?
|
|
|
Message #281472
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The other way around
A RDBMS is the right tool for any complex data centric application. OO is the questionable tool here. However, if you let the database do what it does best, data management, transactions, locking, data business rules, etc. via stored procedures you won't have a problem. There is no impedance mismatch because its a stupid term that hides the real issues. The two systems model different problems and should simply not be joined. Much too much work is being done in the application layer due to a lack of understanding of relational theory.
ODBMS failure was due to its utter inability to compete with the relational data model. OO is NOT A DATA MODEL. ODBMS failure was inevitable and not due to lack of trying.
|
|
|
Message #281479
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ORM and DBMS could be friends
But if it requires genius to understand the reasons to use a persistance API something else is wrong ;-)
(which is the main point of the thread - why isn't Java persistance simpler?)
Well, I am an old JDO fan (I began with LiDO, JRelay, FastObject and Kodo) even if I use Hibernate quite often, but it is very hard to say that are not simple.
But, first of all, ORM is not Java Persistence (IMHO).
JDO over RDBMS, Hibernate, JPA are implementations of ORM concepts.
RDBMS are there, you cannot pretend that they do not exist.
And some people find much more comfortable to transparently save the state of an object (in GoF sense) into a relational database, rather than explicitly have to deal with table and columns.
What I mean is that in a lot of cases RDBMS are there, and this fact is not questionable, and are part of the boundary conditions of your system.
What are you going to do in this cases ?
Thinking at ORM frameworks as (the) Java Persistence Solution is wrong.
ORM frameworks ease the development when you have to use certain persistence technologies. Point.
Change persistence technology and you will change framework (well, this is not necessarily true - see JDO/DataNucleus).
In the end, asking for (an abstract) Java Persistence would be as asking for a Java Communication Protocol.
You have realities called TCP, UDP. You would never ask for a simpler socket.
The same for persistence.
There are certain persistence technologies that can be reasonably unified under a common interaction model, and here JDO community is doing a superb job in trying to extend commonalities, if the persistence technology that you decide to be right for your problem falls into this category then you can use certain frameworks.
No silver bullet, no panacea.
Simple toolbox which you pick the right tool from.
Guido
|
|
|
Message #281483
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The other way around
if you let the database do what it does best, data management, transactions, locking, data business rules, etc. via stored procedures you won't have a problem.
I think we're getting of topic here, but couldn't resist an opinion.
Aparently, you missed the eBay Scalability Architecture paper. I would dare you to implement such a system in stored proceedures.
http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf
ODBMS failure was due to its utter inability to compete with the relational data model. OO is NOT A DATA MODEL. ODBMS failure was inevitable and not due to lack of trying.
What failure? Just a little over 10 years ago we were working with green screens and the most users you had hitting applications we're barely over 1000 in the largest systems in the world. That's why relational databases dominate. The problems were simple, just nuts, so just a crescent wrench was enough... and funny enough today still most of the problems are relatively simple and RDB's are a great tool.
However, point me to one relational database that actually implements to completeness E.F. Codds' relational theory. I speculate there are a 1000 people reading this right now who know they've broken most of the relational theory rules so they could actually achieve some scale. Nobody uses DKNF in a sizable system, so what good ( excuse for superiority ) is the theory if nobody uses it because as a matter of practicality it's unusable?
Most of the new systems written today are OO. Yet, there is no mathematically based OO theory. Does this mean all of todays new systems are somehow flawed and useless? Most would agrue the opposite, that those systems could have never been built without that mathematically theoryless OO approach. So, how does this translate into the value of an OODB to the software developers tool kit?
Versant, is an OODB company and we are far from being a failure. Plenty of cash in the bank and more every quarter. The green screen is gone and business is booming.
Right tool for the job,
-Robert
Versant Corp
|
|
|
Message #281482
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
ORM needs more from SQL for efficent Object Graph construction
3) SQL -vs- VQL.... I do not see any real advantages when it comes to dealing with object graphs. Mind you, the plethora tools available which understand SQL make things easier once you step outside of your oo models. For Versant, we enable this same kind of access (Crystal Reports, etc ) using and ODBC/JDBC bridge type of driver. So, we can do it, but it's just slower than our native VQL.
Ok. Where I was going with this was that it is difficult to build some object graphs using SQL efficiently. For example a entity that has 2 or more 1-M relationships. If you use a single SQL query you end up with a cartesian product (not good). If you break it into multiple queries you may lose "DB read consistency" unless you can explicitly use the MVC timestamp (as you can do with Oracle for example).
Said bluntly, SQL is not great for building *SOME* object graphs. Oracle exposing its MVC timestamp means an ORM vendor can use that to build the object graph *MUCH* more efficiently. I'm wondering if an OODBMS query language would be even better?
|
|
|
Message #281484
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SQL LIMIT OFFSET etc ... limited use for ORM
Perhaps it is not obvious that SQL LIMIT OFFSET etc are only useful when building flat object graphs. As soon as the object graph includes a 1-M relationship you can't use LIMIT OFFSET (or equivilent) as they are row based limits and not object graph based (where you don't know the number of rows in the 1-M relationship).
Don't get me wrong, simple Object graph construction using SQL can be efficient but there are a number of common cases where it is not.
IMO this is the next major challange for ORM in general. Certainly this is how I see it for the future development of Ebean ORM.
|
|
|
Message #281489
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ORM needs more from SQL for efficent Object Graph construction
Said bluntly, SQL is not great for building *SOME* object graphs. Oracle exposing its MVC timestamp means an ORM vendor can use that to build the object graph *MUCH* more efficiently. I'm wondering if an OODBMS query language would be even better?
Geezz... hope this comes across clearly. I've got to catch a plane.
I think the reason I miss understood this is that I ( thinking OODB ) don't think of query as something that creates object graphs. I think of it as something that selects entry points into them.
It's just not the same with an OODB. You see, an OODB bakes all the relationships into the underlying data storage. So, they are always present, never dynamically recalculated on each access as with a relational JOIN.
In an OODB, you simply new a model within a transactional context and everything gets stored. You can control things to not be stored using language key words like "transient" or by not declaring parts of you model to be of a persistent nature.
When you retrieve them, you just do a query with the usual: select * from class where attribute == ( > < range AND OR NOT GROUPBY SORTBY ) >>>Bla bla bla. Once the answer comes back ( set of polymorphic instances ), all relationships are immeidately at your finger tips .... no need to form more queries to dynamically map FK-PK values, etc. The relationship are just there to use regardless of how complex the graph. So, send a message.
Hope this is clear ... I've got to go.
Cheers,
-Robert
Versant Corp
|
|
|
Message #281575
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Lazy Loading network cost?
The relationship are just there to use regardless of how complex the graph.
Hmmm, I think you are talking about the case when the DBMS is in the same process as the object graphs (Is that the case?). Specifically, when your object graphs are on a different box (say an application server) from your DBMS (say on a separate DB server box) - then you need to "materialise" object graphs on the app server (move the data over the wire and materialise object graphs - aka in my view this is the job of the ORM). The developer chooses how much of the object graph to bring back initially (using joins) and if you need more of the object graph after than you lazy load more of the object graph as required (with caveats around DB read consistency).
This is no different if the DBMS is a RDBMS or OODBMS - the issue is that the object graph is being constructed *remotely* from the DBMS over a network (via JDBC/SQL in the relational world). The question IMO becomes is there a more optimal approach for building object graphs on the app server (remote from the DB server) than the typical SQL/JDBC API.
IMO (from a RDBMS view) the answer is yes (either by extensions to SQL/JDBC or by changing the way it is used).
Perhaps lazy loading against an OODBMS has less overall cost but you would still have the network costs to deal with? Hmmm... am I missing something?
|
|
|
Message #281578
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Lazy Loading network cost?
Specifically, when your object graphs are on a different box (say an application server) from your DBMS (say on a separate DB server box) - then you need to "materialise" object graphs on the app server (move the data over the wire and materialise object graphs
You are correct, this loading requirement is a key optimization issue. Versant has always accomplished this "materialization" via one of two Versant calls ( getClosure( ) or groupRead( ) ). I've seen cases where proper use of these calls has changed RPC usage from 100's of thousands to 10s ( zero thousands :-).
The getClosure call takes an obj(or collection of) and you specify a number of levels of referencibility. The subgraph is then loaded across the network.
The groupRead call does the same, but only for the given obj or collection. If you have a model where there is fan out of unwanted objs for a particular use case ( closure wasteful ), then you can use groupRead and build the "pathing" yourself by collecting ids and loading... which means 1 RPC per level of referencibility.
Of course, in some of our API's ( e.g. JDO spec API )you can name and externally associate these "pathings" with a particular member. Regardless, the mechanism is to use the above calls to accomplish the task, only we do the id collection for you along the path.
Right tool for the job,
-Robert
Versant Corp
|
|
|
Message #281589
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Criticism of Java Persistence Frameworks
I read some (but not all) of this discussion and was disappointed to see the discussion was rather concentrated on the technology (software architectures), rather than what needs to be done.
Conceptually, there are certain objects (of given type or types) that the enterprise (or enterprises) need to create to parallel the real-world things that they are concerned with. Once created, they can gain/lose roles (in 'sympathy' with the real-world things) -- we do this by 'code' that deals with real-world events. Some of these objects are 'first class objects' in that they can be identified; others are note (value objects).
Dealing with an event cannot be instantaneous, and indeed, may require distribution across space. That's why the theory of transaction processing was developed.
The relational (tabular) model of data does not really acknowledge the fact that one object can have multiple roles, and can gain/lose them without being destroyed (and real-world objects thus often end up with multiple/incosistent copies in relational databases.
So far, I don't think I said anything that we didn't know in 1988 -- before we had heard of Java, EJB, OODBMSs, ...
So can't we go back to basics and talk about how we solve the above problem, rather than talking about good/bad features of particular architectures, and whether real systems can be built with them?
In the context of Java, the question is how can we create objects, control access to them, add/drop roles, make spatial distribution transparent, ... and ensure that all the required (ACID-like) properties of transaction handling is supported? [We also need import/export data facilities, e.g. using XML -- but this is not a good persistence model per se.]
In the early 90s, I saw much promise in OODBMSs (see above discussion), and later, I also found EJB has a good resonance with enterprise data management requirements. But the plethora of langiages/architectures is not improving things.
Personally, I think the problem is the power of software companies in developing their own competitive solutions (for commercial reasons), rather than user-driven development of standards. One of the reasons we are still talking about SQL and the relational model is that it answered a real enterprise need for efficoent storage of data in a fairly flexible form. Yet 30 years ago, we all knew that systems built using a relational DBMS were easily out-performed by hierarchical and network (Codasyl) DBMSs.
Conclusion: the discussion should centre around enterprise data management: robustness, simplicity (cost to develop application), flexibility (to deal with different types of problem), future-proofed (so the enterprise is not locked into old technologies -- so 'export facilities' are vital).
Mike Brough, Keele Uni (in s/w industry & academia since the 70s).
|
|
|
Message #281670
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Buzzwords re-inventing the wheel
The current persistence problem is a bye-product of gross mismatch between relational database and the object oriented approach of Java. RDBMS is totally unsuitable for representing objects... No patchwork can solve this. RDMS handles 2-D tables... and objects do have a hierarchical structure.
When Java entered the IT world, RDMS were accepted as the de-facto standard for databases. No one dared to question this. A few OO-DBMS attempts already failed in the commercial field even before Java arrived.
JDBC coding tried to be a layer between Java and the RDMS. EJB tried to be the middlemen and handle the persistence.
Then ORM appeared.
ORM is simply re-inventing the wheel. Hibernate application is in fact redefining the data. It all works in simple cases. All these mappings become too complex in a real scenario.
Even statements like "ORM is an alternative to EJB" are just comparing dissimilar concepts when one is certainly not a replacement for the other!
|
|
|
Message #281672
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Buzzwords re-inventing the wheel
Hibernate application is in fact redefining the data. It all works in simple cases. All these mappings become too complex in a real scenario. When this complexity gets outsourced/offshored, it becomes really unmanageable.
There is a great impedance mistmatch between two camps of Java developers - folks who invent frameworks like JPA and Hibernate, and enterprise IT with high level of outsourced/offshore/transient workforce.
The second camp needs robust frameworks where people have little chances to screw things.
I think the reason why Java is successful is not because it runs anywhere - after all C/C++ is available on more platforms, I witnessed different behaviour of threads in Java on Sparc and x86, so testing of Java applications is required on all target platforms.
Java is popular because it is more fool-proof than C++, and as such it is more "consumable". Complex frameworks kind of defeat the purpose of Java, don't you agree?
|
|
|
Message #281688
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RDBMS is totally unsuitable for representing objects.
The current persistence problem is a bye-product of gross mismatch between relational database and the object oriented approach of Java. RDBMS is totally unsuitable for representing objects... No patchwork can solve this. RDMS handles 2-D tables... and objects do have a hierarchical structure.
Well a certain CJ Date would disagree and I'm with him. Much of what some consider Object/relational is what CJ Date would call "Relational done right" for example. Certainly there are RDBMS that handle complex types and inheritance such as Postgres (and these features are included in SQL3 - but not implemented by some major RBDMS Vendors).
That said there are some pretty interesting critics of the SQL language including CJ Date (who pushed Tutorial D as an alternative). For me personally the Object Relational mismatch is mostly with the SQL language and RBDMS vendors not supporting SQL3 things like inheritance and complex types.
In practice though its hard to see RDBMS vendors enhancing or replacing SQL anytime soon... and SQL3 inheritance has not been supported by many of the major databases. So in practice your criticism is valid (although I'd argue that in *theory* a RDBMS done right would be just as good as an OODBMS - time will tell).
Perhaps mass Postgres adoption would speed things up :)
|
|
|
Message #281693
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Persistence Frameworks - a new hope
I absolutely agree with Ibrahim Levent in his criticism of Java Persistence Frameworks.
While simply storing away and retrieving objects in and from a relational database might be sufficient for some simple applications, when it comes to fully utilize the power of a relational database for example when building complex dynamic queries featuring aggregation and transformation of data is required, ORM solutions fail – simply because the entire approach is unsuitable for these kind of tasks.
And yes XML mappings should be immediately abandoned. I never understood how anyone could have possibly come up with that idea in the first place, nor do I understand why anyone ever thought it was a good idea. Unfortunately annotations aren’t any better. Both XML mappings and annotations are not part of the solution but rather part of the problem.
But believe it or not, there is hope. There is a persistence solution available that allows you to build complex dynamic queries in code – absolutely string free and without the need to learn a new query language – giving you exactly the SQL you want. A solution that does not use XML mappings or annotations but uses java classes to represent the data model. A solution that offers save and easy metadata access and even lets you add extra application specific metadata. A solution that is lightweight, configuration free and works completely without bytecode manipulation. And a solution that offers applications a much higher degree of integration and thus a much better separation of model and view.
The persistence solution I am talking about is called Empire-db, its Open Source and it is currently in the Apache Incubator. For more information see http://empire-db.org
For everyone interested I especially recommend the article “What's wrong with Hibernate and JPA” that can be found here:
http://incubator.apache.org/empire-db/empiredb/hibernate.htm
|
|
|
Message #281769
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java Persistence Frameworks - a new hope
And yes XML mappings should be immediately abandoned. I never understood how anyone could have possibly come up with that idea in the first place
So your way is best and everyone should just follow you ? The are many different types of architecture and you think you know best for all ? Ok.
But believe it or not, there is hope.
Hallelujah.
There is a persistence solution available that allows you to build complex dynamic queries in code
There are many such refactorable query languages, LIQUidForm was mentioned on here just 2 days earlier, and JaQu, and ... LINQ.
A solution that offers save and easy metadata access
So your solution requires that people use your persistence solutions classes ? and it is tied to RDBMS ? and the model classes extend your classes ? And this is the future ?
|
|
|
Message #281793
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java Persistence Frameworks - a new hope
For everyone interested I especially recommend the article “What's wrong with Hibernate and JPA” that can be found here:
http://incubator.apache.org/empire-db/empiredb/hibernate.htm
From the above link:
.... and there are plenty of reasons why annotations are clearly the superior solution over XML mapping.
I know that annotations have a certain appeal in a lot of people, but the plenty of reasons are mainly...because you have all in the same file.
Great!!
Another pearl is metadata access.
In the article it is mentioned the need to know if a certain field is mandatory.
Considering flat mapping case, where the same table hosts rows representing different subclasses, it is quite evident that columns of fields belonging to a certain class cannot be declared as NOT NULL, even if the corresponding field must be not null by business rule.
It is not clear how empire-db solves the problem without extra metadata.
I would not comment about query simplicity.
In the conclusion of the article I have the impression that the authors think at ORM solutions as a way to access relational data in a relational way with an API instead of jdbc+SQL, objects as a synonymous of things, customer is just the table of customers.
Left any comment as an exercise to the reader.
Guido
|
|
|
Message #281797
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: RDBMS is totally unsuitable for representing objects.
Well a certain CJ Date would disagree and I'm with him. Much of what some consider Object/relational is what CJ Date would call "Relational done right" for example. Certainly there are RDBMS that handle complex types and inheritance such as Postgres (and these features are included in SQL3 - but not implemented by some major RBDMS Vendors).
CJ Date and late Dr Codd advocated RDMS as a panacea and later went on to criticize SQL. Somewhere read that George Bernad Shaw wrote a severe criticism of his own play in London Times or so. (He defended it as of saving the trouble for all other critics!) All that SQL databases proved was that they break at high volume or on wrong SQL!
Dates' book plays around with the power of SQL with three simple tables S, P and SP. The multi-level SQLs you see there are nothing but mathematical exercises and no one dare to use them in real life with large amount of data.
Relational experts's claim of the power of SQL one saw only in books. When SQL applications finally got into production we see that all of them depended heavily on Stored Procedures... many of which are as big as full programs with many SQLS and FETCH-es. Even without Java in the picture I never accepted the over-use of stored procedures....RDMS became popular because and only because, many vendors were able to put an index on a simple table and provided SQL calling it a DBMS! Many didn't have anything called a 'DBMS' to handle the data! Once the concept became popular, the big vendors just utilized it. In the absence of any other options on Windows/Unix no one complained!
Date's Introduction to Database Systems earlier included a hybrid langauge called UDL - Unified Data Language - mixing CODASYL and SQL systems. Date also commented or implied that a relational database could be implemented using or modifying a CODASYL model. Cullinet (later CA) eventually did that by supporting SQL in the network database IDMS on mainframe.. but it was perceived too late or no one noticed because of the platform!
A database based on E-R model would have easily represented any object hierarchies.
Today I was sitting with an EJB application running on Weblogic with a local Sybase database and accessing a remote Oracle database. Some APIs towards Oracle was clocking times of the order of 100s of seconds (clocktime) and one could see the transactions active in Weblogic console. This also blocked the local database. I could not comprehend how we call this a transaction at all! In a traditional OLTP scenario, a transaction is visible on any monitor screen for a fraction of a second - worst case a few seconds! Any discussion of persistence here is meaningless unless we clearly define what exactly is a transaction in the modern era!!
|
|
|
Message #284369
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Desgin Patterns (DAO)
You may want to look into design patterns and Jt (Java Pattern Oriented Framework). It solves some of the issues that you identify (Simpler persistence API).
People don't think in terms of tables and columns. Therefore the "limitation" of the relational approach. A higher level of abstraction (DAOs) is called for. Locking, transactions, DB mapping, caching, events, etc should be handled automatically by the DAO implementation.
http://jt.dev.java.net.
http://jt.dev.java.net/servlets/ProjectDocumentList
|
|
|
Message #284827
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Criticism of Java Persistence Frameworks
Thanks for valuable comments. I know some ORM frameworks already have solid solutions for some of these problems. Besides, I don’t target any specific solution or framework. My criticism is general and includes Java standard solutions. Most of criticism items are based on ERP(most of them uses RDBMS) development experience and doesn’t include Non-relational or Object-oriented DBMSs.
I believe that current solutions will get better that is why I make this blog post.
|
|
|
Message #299186
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ORM
I don't want to get involved in a fight over ORM but I started a library for working with databases in a fundamentally different way than ORM. You could build ORM on top of it, I suppose, but it's not really my goal. If you are interested in contributing or trying it out, I can give you some more details. It's kind of stalled as I've stretched myself too thin. It's also a problem area with a lot of projects so I'm not sure it's worth putting a lot of time into.
I'm interested to know more. Can you provide some details? Thanks!
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Download the entire book of Jakarta-Struts Live and learn about Struts MVC, Tiles, the Validator, DynaActionForms, plug-ins, internationalization, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
