Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Using JDO in an already developed J2EE application

 
Ruban Silvester
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Friends
We have developed a J2EE application which uses entity beans(BMP and CMP) to store information in database. Initially we used oracle 8i, now we have to modify our application so that it would be database independent. In this regard, i thought of using JDO. Now if i have to use JDO, should i have to remove the existing entity beans(BMP and CMP) and replace that with JDO or else can i add the JDO layer to the existing entity beans.
Help me in this regard
Thanx & Regards
Ruban
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can most definitely replace the JDBC code inside your BMPs with JDO. However, you really can't replace CMPs without changing the "client" code unless you've encapsulated access to the CMPs into some kind of Data Access Objects. If you're ok with that (touching the client code), then you can replace the CMPs with JDO persistent classes.
 
Ruban Silvester
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanx Lasse Koskela.
How would be the performance when i add JDO to BMP? Which JDO implementation supports DDL, subqueries.
Thanx & Regards
Ruban
 
Renat Zubairov
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ruban Silvester:
Thanx Lasse Koskela.
How would be the performance when i add JDO to BMP? Which JDO implementation supports DDL, subqueries.
Thanx & Regards
Ruban

That's the problem I also run into. JDO in my opinion is to intrusive. You have to use JDOQL (BTW when CMP 2.0 was done, the same problem appears, for example I suffer from lack of count(*) function, the same problem in JDO) So, many vendors support some JDOQL cheats:
http://www.jdogenie.com/features.html see JDOQL features
But, once you are using it - you have the problem with vendor lock in.
So, all claims of JDO fans like "JDO is a standart hence it's portable" are meaningless for complex applications.
[ February 04, 2004: Message edited by: Renat Zubairov ]
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Renat Zubairov:
That's the problem I also run into. JDO in my opinion is to intrusive.

In what way? JDO is far less intrusive than almost every other persistance tool.
Originally posted by Renat Zubairov:
You have to use JDOQL (BTW when CMP 2.0 was done, the same problem appears, for example I suffer from lack of count(*) function, the same problem in JDO) So, many vendors support some JDOQL cheats:
http://www.jdogenie.com/features.html see JDOQL features
But, once you are using it - you have the problem with vendor lock in.
So, all claims of JDO fans like "JDO is a standart hence it's portable" are meaningless for complex applications.

There are always going to be parts of the spec that are lacking and vendors that step up to fill those gaps. However, those really important gaps (such as count(*) in JDO) are going to be supported by all vendors. These portability issues are almost always extremely minor and easily fixed if you did need to change implementations.
That is not to say that I don't have issues with JDO... far from it. However, I don't think the use of small vendor extensions are a major problem.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic