• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Junilu Lacar
  • Martin Vashko
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Scott Selikoff
  • salvin francis
  • Piet Souris

Why Kodo JDO?

 
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We considered JDO for a project recently (getting so far as deciding that Kodo would probably be our solution choice), but came to the conclusion that the only thing that a JDO layer offered was "the programmers don't have to know SQL".

So, what does one gain by using JDO - specifically Kodo? There are a number of tuning tricks that can be done in SQL if your queries are slow, are there similar programming tricks that can be done with kodo if performance isn't what you'd hoped?

Did we miss something else? If your programming team has decent experience and understanding of SQL and query tuning, is there any reason to use a JDO?
 
author
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One aspect is all about developer productivity.

Consider an application with X thousand lines of code under management, which delivers a set of features for the business to use. What I'm most interested in here are the lines of code which are actually in the version control system, which would include descriptor files which drive code generation tools but excludes the code generated by those tools. The amount of code under management has a direct relationship to the resource cost of maintinaing the application and enhancing the features it delivers.

JDO lets developers think and work at a higher level of abstraction if they want to. Object mappings are managed as configuration data outside the application code. Algorithms for persistence by reachability, dirty tracking, etc. mean that very little code has to be written to actually deal with persistence concerns. The concept of "transparent persistence" means persistnece is transparent to the domain object model, so persistent objects behave comparably to their transient counterparts and can be tested outside the persistence environment.

The lack of constraints facilitates object models which go beyond the JavaBean conventions where apprioriate: no problem with final classes, private fields with no accessors, etc.

All of this adds up to a smaller codebase delivering the same features with a level of abstraction which is more related to business features than to infrastructure concerns. From the business stakeholders' perspective, this means increased developer productivity.

Of course you can still tune Kodo in many ways, and JDO 2.0 adds fetch groups and native SQL queries to the developers' arsenal. So you can fall back to SQL if you have to, whilst retaining the benefits of a transparent persistence solution.

JDO is remarkably efficient, in part due to its non-reflective architecture, in part due to its automatic dirty-checking, and in part due to the competition between vendors (including SolarMetric) to make their products stand out in the market place.

Cheers, Robin.
 
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We considered JDO for a project recently (getting so far as deciding that Kodo would probably be our solution choice), but came to the conclusion that the only thing that a JDO layer offered was "the programmers don't have to know SQL".

Productivity is pretty important, in developing business systems or database applications. Writing all that JDBC code by hand will probably take 30% of the devlopment time & effort in your project, and you've probably noticed that it's pretty much boilerplate.

If you get an engine to do the DB access & mapping for you, you wipe that task off your plate. You also get the flexibility to change or re-map your schema, and the engine will allow use of different access paths & queries off the same set of mappings. Which is pretty much win-win all round.

Feature wise you can look for things like configurable fetch, reference joining, integration features, query result expressions to retrieve large data structures, caching for commonly-used data etc.


For one Order-OrderLines-Product example, we can see 1500+ rows per second retrieved. This case used the query features to specify retrieval of the subordinate data, and should be widely applicable since Order-Lines-Product is such a common business example. Only basic hardware and a Java database were needed to achieve this.

Hope this helps.


Cheers,
Thomas Whitmore
www.powermapjdo.com
 
Did you ever grow anything in the garden of your mind? - Fred Rogers. Tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!