/ / ORM (Object-relational mapping)

Tuesday, July 10, 2007

thumbnail

ORM (Object-relational mapping)

5 Comments
Object-Relational mapping (aka O/RM, ORM, and O/R mapping) is a programming technique for converting data between incompatible type systems in databases and Object-oriented programming languages. This creates, in effect, a "virtual object database" which can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.

Problem description

Data management tasks in object-oriented (OO) programming are typically implemented by manipulating objects, which are almost always non-scalar values. Consider the example of an address book entry, which represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "person object" with "slots" to hold the data that comprise the entry: the person's name, a list (or array) of phone numbers, and a list of addresses. The list of phone numbers would itself contain "phone number objects" and so on. The address book entry is treated as a single value by the programming language (it can be referenced by a single variable, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.

Many popular database products, however, such as SQL DBMS products, can only store and manipulate scalar values such as integers and strings, organized within tables.

The programmer must either convert the object values into groups of simpler values for storage in the database (and convert them back upon retrieval), or only use simple scalar values within the program. Object-relational mapping is used to implement the first approach.

The crux of the problem is translating those objects to forms which can be stored in the database, and which can later be retrieved easily, while preserving the properties of the objects and their relationships; these objects are then said to be persistent.

Implementations

The most common type of database used is the relational database, which predates the rise of object-oriented programming in the 1990s. Relational databases use a series of tables to organize data. Data in different tables are associated through the use of declarative constraints, rather than explicit pointers or links. The same data that can be stored in a single object value would likely need to be stored across several of these tables.

An object-relational mapping implementation would need to systematically and predictably choose which tables to use and generate the necessary SQL. In overview, the impedance mismatch between the architectural approach of the object oriented application such as built in Java and where the data is stored in a relational database management system (RDBMS) such as Oracle or IBM's DB2 creates a rather complex set of challenges to deal with in order to accomplish tasks such as performance, linear scalability, manage the CRUD operations for even the most complex relationships without slowing down, eliminate coding SQL - JDBC - Java to save time and create consistency in how this is handled, make maintenance and future application changes simple, requiring little or no effort, etc. The real values in using an ORM tool is to save time, simplify development (i.e. the ORM tool handles the complexity for the developer), increase performance or scalability, and minimize architectural challenges related to inability of the ORM tool or developer's experience.

Many packages have been developed to reduce the tedium of developing object-relational mapping systems by providing libraries of classes which are able to perform mappings automatically. Given a list of tables in the database, and objects in the program, they will automatically map requests from one to the other. Asking a person object for its phone numbers will result in the proper query being created and sent, and the results being translated directly into phone number objects inside the program. [1]

From a programmer's perspective, the system should look like a persistent object store. One can create objects and work with them as one would normally, and they automatically end up in the database.

In practice, however, things are never quite that simple. All O/RM systems tend to make themselves visible in various ways, reducing to some degree one's ability to ignore the database. Worse, the translation layer can be slow and inefficient (notably in terms of the SQL it writes), resulting in programs that are slower and use more memory than code written "by hand."

A number of O/RM systems have been created over the years, but their effect on the market seems mixed. Considered one of the best was NeXT's Enterprise Objects Framework (EOF), but it failed to have a lasting impact on the market, chiefly because it was tightly tied to NeXT's entire toolkit, OpenStep. It was later integrated into NeXT's WebObjects, the first object-oriented Web Application Server. Since Apple Computer bought NeXT in 1997, EOF provides the technology behind the company's e-commerce Web site, the .Mac services and the iTunes Music Store. Apple provides EOF in two implementations: the Objective-C implementation that comes with the Apple Developers Tools and the Pure Java implementation that comes in WebObjects 5.2. Inspired by EOF is the open source Apache Cayenne. Cayenne has similar goals to EOF and aims to meet the JPA standard.

An alternative approach is being taken with technologies such as RDF and SPARQL, and the concept of the "triplestore". RDF is a serialization of the subject-predicate-object concept, RDF/XML is an XML representation of it, SPARQL is an SQL-like query language, and a triplestore is a general description of any database that deals with a triple.

More recently, a similar system has started to evolve in the Java world, known as Java Data Objects (JDO). Unlike EOF, JDO is a standard, and several implementations are available from different vendors. The Enterprise Java Beans 3.0 (EJB3) specification also covers this same area. There has been standards conflict between the two standards bodies in terms of pre-eminence. JDO has several commercial implementations, while EJB 3.0 is still under development. However, most recently another new standard has been announced by JCP to bring these two standards together and make the future standard something that works with various Java architectures. Another example to mention is Hibernate (Java), the most used framework of O/R mapping in the Java world that has inspired the EJB3 specification.[verification needed]

In the Web framework Ruby on Rails, object-relational mapping plays a central role and is handled by the ActiveRecord wrapping tool. A similar role is played by the DBIx::Class module for the Perl based Catalyst framework, although many other choices are possible.

Python enjoys availability multiple ORMs such as SQLObject, SQLAlchemy, Devaju, PyDAO etc. SQLAlchemy actually is much more that ORM. Many python frameworks support one or multiple ORMs

Frameworks included in the comparison: Features included in the comparison: 0. Relationally Complete. 1. Release Version Number (To indicate which version has been referred to) 2. "Free" as in "free beer" - no license fee 3. "Free" as in "free speech" - source available 4. Has mapping GUI 5. Persists arbitrary classes (no special superclass or interface required) 6. Requires manual SQL building 7. RDBMS support/independence 8. EJB support (for whoever needs it) 9. Supports relationships between objects 10. Mapping supports grouping (GROUP BY clause) 11. Mapping supports aggregate functions (count(), avg(), etc.) 12. Includes full support of lazy resolution of all queries 13. Maintains single identities for objects returned from queries (aka "uniquing") (i.e., AddressFinder.findById(1) == AddressFinder.findById(1)); 14. Resolves Circular Identities (aka "uniquing") (i.e., "account == account.getCustomer().getAccount()") 15. Generates Mapping as well as the Java Objects themselves, so you don't duplicate information in the Java Objects and the related mapping information. Comments: (who says this is a GoodThing? I don't want my DomainObject classes' source generated by some tool) Well, for O/R mapping you have to define somewhere the fields and how they're persisted. This usually at least consists of class, field names, and types. If you write the class and the mapping, you violate OnceAndOnlyOnce and DontRepeatYourself since the mapping file duplicates all the information that is contained in the class itself. The mapping gives you all the information you need to generate the object itself, so why not generate it? Why write code that you don't have to? There's a difference between a DomainObject and a DataAccessObject. DomainObjects have behavior-intensive methods that implement various responsibilities allocated to them from application requirements. Is the mapping tool going to generate the code for all my DomainObject's responsibilities? I doubt it. It probably generates only a simple class skeleton consisting of variable declarations and getters and setters - which I may not even want. And it probably can't preserve non-generated additions when the need arises to re-generate due to class shape or mapping changes. The DomainModel is the heart of the system - see http://domainlanguage.com/book.html - and can be written and tested before any persistence-related code is even written. Plus, what happens if you want to switch persistence technologies, such that your mapping and the tool that generates it becomes irrelevant? Many of the problems you describe relate to PassiveCodeGeneration and not ActiveCodeGeneration (regenerate at every build, NEVER MODIFY). There are ways to effectively merge business logic and generated objects. Basically it boils down to inheritance or composition, either one is effective. This is often called a the MartiniGlassArchitecture? b/c it allows you to seamlessly (ThereIsNoSuchThingAsSeamless) merge business and generated data logic into one unified DomainModel. Any tool, whether a language or a code generator, (Java and CeeSharp can also be viewed as code generators) can become obsolete. Evaluate your risks accordingly. Preferably, find an open source solution, get write access, then make sure it doesn't become obsolete. ;) 16. Supports Composite Primary Keys 17. Aggregate Mappings - Single field maps to multiple fields in database. http://martinfowler.com/eaaCatalog/embeddedValue.html 18. Supports both many to many and one to many associations 19. Supports collections of Strings, Integers, Dates, etc 20. Supports inheritance / polymorphic queries 21. Supports one to one associations 22. Can fetch associated objects using SQL outer joins 23. Support for optimistic locking / versioning 24. Support for Unit of work / object level transactions 25. Providing a SUN JDO compliant API 26. Providing an ODMG compliant API 27. Requires "extra" database tables holding locks, metadata, etc. 28. Supports multiservers (clustering) and simultaneous access by other applications without loss of transaction integrity 29. Requires code generation / bytecode processing 30. Requires RuntimeReflection? 31. Query Caching - Built-in support (developer writes no code). The following two identical queries will hit the database only once. The second time cached results will be returned. Address address = AddressFinder.selectByPrimaryKey(new Long(1)); assertTrue(address == AddressFinder.selectByPrimaryKey(new Long(1))); 32. Supports sequences and identity/autoincrement columns for primary key generation (Not using the incorrect SELECT MAX method!) 33. Supports ternary associations 34. Supports mapping of one class to multiple tables 
 Comments: Any comments on this? Is this really a useful thing to do? If the tables are badly designed, fix them!
I believe why this question can is solve by convenient UML diagram
We think this is a Bad Thing: http://www.hibernate.org/Documentation/Delegate
Sometimes legacy databases leave you no choice.

I believe that for a general purpose persistence framework, this type of support is absolutely critical. The reason is that in many development shops, different people control the object and data models. In the real world, either or both could be well designed or poorly designed. Either or both could be a legacy model, or new. Even with good design this is desirable. Object modeling and relational modeling represent the same conceptual model differently - they cannot be expected to be 1 for 1. For example, tables are needed for many to many relationship - a class is not needed for this, as each object merely has a collection of the other. 35. Supports mapping of multiple classes to one table 36. Supports persistence of properties through private fields 37. Supports persistence of properties through accessors (get/set methods) 38. Supports disconnected operations: Populate objects from database, disconnect, create/remove/modify objects (on client, another JVM) and apply changes to database (much) later Comments and explanations of the features 1. Release Version Number (To indicate which version has been referred to) 2. "Free" as in "free beer" - no license fee
  • Abra: Yes
  • BasicWebLib - YES
  • DB Visual Architect - No
  • Castor: Yes
  • CayenneFramework: Yes
  • CocoBase: No
  • DataBind: Yes
  • EdgeXtend: No
  • EnterpriseObjectsFramework: No, but cheap ($700 that also includes WebObjects, unlimited clients and cpu)
  • Expresso: Yes
  • FireStorm - NO but very cheap ($200)
  • FrontierSuite? for J2EE & J2SE: No(Free Evaluation Copy can be downloaded at www.objectfrontier.com)
  • FrontierSuite? for JDO: No(Free Evaluation Copy can be downloaded at www.objectfrontier.com)
  • Hibernate: Yes
  • Hydrate: Yes
  • iBATIS DB Layer - YES
  • Infobjects ObjectDRIVER: NO
  • Jakarta ObjectRelationalBridge: Yes
  • Java Ultra-Lite Persistence (JULP): yes
  • JaxorFramework: Yes
  • JdoGenie: No (but free for non-commercial/academic use)
  • JDX - No
  • KodoJdo: No (but free for eligible non-commercial/academic use)
  • LiDO: See XIC
  • Lychee: Yes
  • O/R Broker: Yes
  • PowerMapJdo: Commercial
  • Signsoft intelliBO: No (but free for eligible non-commercial/academic use)
  • SimpleOrm: Free (Apache license).
  • Sql2java: Free (GPL)
  • The ProductivityEnvironmentForJava (PE:J): Free Limited Edition available
  • TopLink: Evaluation copies can be downloaded from Oracle Technology Network. OTN licenses such downloads according to the OTN License Agreement (http://otn.oracle.com/software/htdocs/devlic.html) which basically says as soon as you are no longer evaluating/prototyping, you need to buy a license.
  • VBSF: No
  • XIC: No
3. "Free" as in "free speech" - source available 4. Has mapping GUI 5. Persists arbitrary classes (no special superclass or interface required)
  • Abra: No
  • BasicWebLib: No
  • Castor: Yes (but need to implement Timestampable if reading/writing in separate tx)
  • CayenneFramework: No
  • CocoBase: Yes
  • DataBind: Yes
  • DB Visual Architect - No
  • EdgeXtend: No, but developer defines interfaces using object model specification
  • EnterpriseObjectsFramework: No
  • Expresso: No
  • FrontierSuite? for J2EE & J2SE: Yes
  • FrontierSuite? for JDO: Yes
  • Hibernate: Yes
  • Hydrate: Yes, though see documentation to understand if you'd want to.
  • iBATIS DB Layer - YES (JavaBeans, Maps, Primitive Wrappers, Collections, XML etc.)
  • Infobjects ObjectDRIVER: Yes
  • Jakarta ObjectRelationalBridge: Yes
  • Java Ultra-Lite Persistence (JULP): No
  • JaxorFramework: No (need to define a base entity)
  • JdoGenie: Yes
  • JDX: Yes
  • KodoJdo: Yes
  • LiDO: See XIC
  • Lychee: Yes (works with POJOs not requiring them to implement any interfaces or extend any classes)
  • O/R Broker: Yes (True POJO support, not just JavaBeans and Maps. Respects encapsulation)
  • PowerMapJdo: Yes
  • Signsoft intelliBO: Yes
  • SimpleOrm: No, persistence has issues that you need to be aware of.
  • SpadeSoft XJDO: Yes
  • The ProductivityEnvironmentForJava (PE:J): Yes
  • TopLink: Yes
  • VBSF: Yes
  • XIC: Yes
6. Requires manual SQL building 7. RDBMS support/independence
  • Abra: JDBC (PostgreSQL, Oracle, Sybase, MySQL, DB2)
  • Castor: DB2, HypersonicSQL, Informix, InstantDB, Interbase, MySQL, Oracle, PostgreSQL, SAP DB, SQL Server, Sybase, Generic (for generic JDBC support)
  • CayenneFramework: Ships with adapters for Oracle, Sybase, MySQL, PostgreSQL, HSQLDB, Firebird, OpenBase, DB2, SQLServer, and a generic JDBC one.
  • CocoBase: JDBC
  • DataBind: JDBC
  • DB Visual Architect: JDBC
  • EdgeXtend: ODBC, optimized for Oracle, Sybase, DB2, Informix, SQLServer
  • EnterpriseObjectsFramework: JDBC, but special for Oracle, OpenBase, (few others from RDBMS vendors)
  • Expresso: JDBC
  • FrontierSuite? for J2EE & J2SE: JDBC (Oracle, SQL Server, DB2, Sybase, Informix, MySQL, Hypersonic SQL, PointBase?, Cloudscape)
  • FrontierSuite? for JDO: JDBC (Oracle, SQL Server, DB2, Sybase, Informix, MySQL, Hypersonic SQL, PointBase?, Cloudscape)
  • Hibernate: JDBC, special for Oracle, DB2, Sybase, MS SQL Server, PostgreSQL, MySQL, HypersonicSQL, Mckoi SQL, SAP DB, Interbase, Progress, Pointbase
  • Hydrate: most JDBC driver-supported RDBMSs
  • iBATIS DB Layer - Any RDBMS that has a JDBC driver.
  • Infobjects ObjectDRIVER: any ODBC compliant - optimized for Oracle via OCI
  • InterSystems Cache: Can create both RDBMS or Object Schemas. Includes a class 3 JDBC driver.
  • Jakarta ObjectRelationalBridge: JDBC, special dialect support for Db2, Hsqldb, Informix, MsAccess?, MsSQLServer, MySQL, Oracle, PostgreSQL, Sybase, Sapdb.
  • Java Ultra-Lite Persistence (JULP): any with JDBC driver
  • JaxorFramework: JDBC
  • JdoGenie: JDBC (Sybase, Oracle, MySQL, DB2, Microsoft SQL Server, Informix, Informix SE, Pointbase, Interbase, Firebird, Postgres, SAP DB)
  • JDX: JDBC
  • KodoJdo: JDBC (Oracle, DB2, MS SQL Server, Sybase, Informix, MySQL, Postgres, Hypersonic, InstantDB, Pointbase, FoxPro, MS Access, Daffodil, Cloudscape)
  • LiDO: See XIC
  • Lychee: Oracle 10g, Oracle 9i, Oracle 8i
  • O/R Broker: Any JDBC compliant RDBMS.
  • PowerMapJdo: JDBC with special for Oracle, SQLServer, MySQL, PointBase? and others
  • Signsoft intelliBO: JDBC but special for PointBase?, Oracle, MS SQL, IBM DB2, Informix, InstantDB, Interbase, MySQL, Pervasive, PostgresQL, Progress, SapDB, Sybase
  • SimpleOrm: JDBC, with DB specific drivers to handle incompatibilities.
  • SpadeSoft XJDO: Supports all JDBC drivers available in the market
  • Sql2java: JDBC, with DB specific drivers to handle incompatibilities.
  • The ProductivityEnvironmentForJava (PE:J): JDBC, optimized for Oracle, IBM DB2/UDB, MS SQLServer.
  • TopLink: JDBC, special dialect support for MS Access, Cloudscape, DB2, DBase, Informix, Sybase, Oracle, PointBase? and Microsoft SQL Server.
  • VBSF: JDBC
  • XIC: JDBC but special for Oracle, DB2, Sybase, Informix, SQLServer, MySQL PostgreSQL, McKoi, InstantDB, HSQLDB, PointBase?, Cloudscape, Unisys
8. EJB support (for whoever needs it)
  • Abra: No (why would you use it??)
  • BasicWebLib - PostgreSQL support, MySQL, others planned
  • Castor: No
  • CayenneFramework: works just fine inside EJBs, allows both Cayenne and container transactions
  • CocoBase: Yes
  • DataBind: ?
  • EdgeXtend: Yes
  • EnterpriseObjectsFramework: No, only as a client to external beans
  • Expresso: Yes
  • FrontierSuite? for J2EE & J2SE: Yes. EJB CMP and BMP. EJB 2.0 and 1.1 (Weblogic, Websphere, Oracle 9i, JBoss, Orbix E2A J2EE, JRun, Orion, HP AS)
  • FrontierSuite? for JDO: Yes (Weblogic, Websphere, Oracle 9i, JBoss, Orbix E2A J2EE, JRun, Orion, HP AS)
  • Hibernate: support for stateful/stateless session beans and BMP entity beans, JTA, JNDI, JMX integration
  • Hydrate: will work in a container
  • iBATIS DB Layer - Stateful/Stateless session beans, Global Transaction (JTA), JNDI DataSources? and BMP -- Spring integration for those who dislike EJB
  • Infobjects ObjectDRIVER: No, not yet
  • InterSystems Cache: Yes - define the table and it spits out the EJBs.
  • Jakarta ObjectRelationalBridge: full support for SessionBeans and BMP EntityBeans, JNDI, JTA & JCA integration
  • Java Ultra-Lite Persistence (JULP): yes
  • JaxorFramework: Yes, designed to run within any J2EE container, or can run outside of container.
  • JdoGenie: Yes
  • JDX: Yes (BMP and O/R Mapping for SessionBeans, JNDI)
  • KodoJdo: Yes
  • LiDO: See XIC
  • Lychee: No
  • O/R Broker: Yes
  • PowerMapJdo: Supports container environment
  • Signsoft intelliBO: Yes
  • SimpleOrm: Session Beans Supported. Entity Beans are not simple to use!
  • SpadeSoft XJDO: Yes
  • Sql2java: No
  • The ProductivityEnvironmentForJava (PE:J): auto-generates configurable Session EJB facade layer with JDO Persistence, support for BMP Entity EJB, JNDI, JTA, and JCA Integration
  • TopLink: Yes - BMP; CMP 1.1, CMP 2.0; Session beans + JTA integration
  • VBSF: Yes
  • XIC: Yes
9. Supports relationships between objects 10. Mapping supports grouping (GROUP BY clause) 11. Mapping supports aggregate functions (count(), avg(), etc.) 12. Includes full support of lazy resolution of all queries
  • Abra: Sort of (some developer code is needed to determine how much is retrieved and when)
  • BasicWebLib - NO
  • Castor: Yes (Lazy Loading)
  • CayenneFramework: Yes, lazy relationship reading, object "faults" (dynamic proxies)
  • CocoBase: Yes
  • DataBind: No
  • DB Visual Architect: Yes
  • EdgeXtend: Yes, provides lazy fetch of database queries
  • EnterpriseObjectsFramework: Yes, lazy relationship reading, object "faults" (dynamic proxies)
  • Expresso: ?
  • FrontierSuite? for J2EE & J2SE: Yes
  • FrontierSuite? for JDO: Yes (Within JDO scope)
  • Hibernate: Yes, object "faults" (runtime CGLIB bytecode-generation for proxies), lazy relationship reading
  • Hydrate: Yes, but why should you if you can load any number of dependent objects without running subqueries?
  • iBATIS DB Layer - YES (w/cglib), Collections, Lists and PaginatedList? (List impl. with pages, next/prev functions etc.)
  • Infobjects ObjectDRIVER: Yes
  • InterSystems Cache: ?
  • Jakarta ObjectRelationalBridge: Yes + dynamic proxies for all relationships
  • Java Ultra-Lite Persistence (JULP): no
  • JaxorFramework: Uses lazy dynamic proxies, so developers never have to write their own lazy code.
  • JdoGenie: Yes (fully transparent - no proxies etc.)
  • JDX: Yes
  • KodoJdo: Yes
  • LiDO: See XIC
  • Lychee: Yes, lazy relationship loading.
  • O/R Broker: On sub-queries that map to java.util.Collection interface.
  • PowerMapJdo: Yes
  • Signsoft intelliBO: Yes
  • SimpleOrm: Yes, lazy relationship loading and delayed query execution.
  • SpadeSoft XJDO: Yes
  • Sql2java: Yes
  • The ProductivityEnvironmentForJava (PE:J): Yes
  • TopLink: Yes
  • VBSF: Yes
  • XIC: Yes
13. Maintains single identities for objects returned from queries (aka "uniquing") (i.e., AddressFinder.findById(1) == AddressFinder.findById(1));
  • Abra: Yes (by object ID)
  • BasicWebLib - NO
  • Castor: Yes
  • CayenneFramework: Yes (normally in the session scope, but can be done in any scope you want)
  • CocoBase: ?
  • DataBind: No
  • DB Visual Architect: Yes
  • EdgeXtend: Yes
  • EnterpriseObjectsFramework: Yes (in and outside of the application scope)
  • Expresso: ?
  • FrontierSuite? for J2EE & J2SE: Yes
  • FrontierSuite? for JDO: Yes
  • Hibernate: some proxy issues (in the session scope)
  • Hydrate: Yes, strict.
  • iBATIS DB Layer: No
  • Infobjects ObjectDRIVER: Yes
  • InterSystems Cache: ?
  • Jakarta ObjectRelationalBridge: Yes
  • Java Ultra-Lite Persistence (JULP): ?
  • JaxorFramework: Yes
  • JdoGenie: Yes
  • JDX: Yes (intra-query)
  • KodoJdo: Yes
  • LiDO: See XIC
  • Lychee: No (Will be two different instances in memory that are equal. Was intentionally designed not to use object caching to avoid hassle associated with it.)
  • O/R Broker: Yes, within same Query or Transaction session. Outside of that would not be threadsafe.
  • PowerMapJdo: Yes
  • Signsoft intelliBO: Yes
  • SimpleOrm: Yes, and with multi field primary keys. (I do not think that a tool can be called an ORM if it does not do this.)
  • SpadeSoft XJDO: Yes
  • Sql2java: Yes
  • The ProductivityEnvironmentForJava (PE:J): Yes
  • TopLink: Yes
  • VBSF: Yes
  • XIC: Yes
14. Resolves Circular Identities (aka "uniquing") (i.e., "account == account.getCustomer().getAccount()") 15. Generates Mapping as well as the Java Objects themselves, so you don't duplicate information in the Java Objects and the related mapping information.
  • Abra: Yes (Mapping, SQL, and classes are all generated from XML; also the above always generate/ and business code can be solved by using our 'descendant' pattern. In this a class defined in the map file, (which is generated every build) can have a descendant which is where the business/application code will go. In the mapping-factories when retrieving from the database the generated code knows to create the instance of the descendant class (which is a hand-written class containing business methods))
  • BasicWebLib - NO
  • Castor: No
  • CayenneFramework: Yes
  • CocoBase: Yes
  • DataBind: No
  • EdgeXtend: Yes
  • EnterpriseObjectsFramework: Yes
  • Expresso: Yes
  • FrontierSuite? for J2EE & J2SE: Yes. Both code and mapping information is generated from an object model through support for Model Driven Architecture (MDA). The behaviour intensive methods aka business logic is maintained separately from the model so that any domain model changes do not result in a loss of these methods.
  • FrontierSuite? for JDO: Yes. Both code and mapping information is generated from an object model through support for Model Driven Architecture (MDA). The behaviour intensive methods aka business logic is maintained separately from the model so that any domain model changes do not result in a loss of these methods.
  • Hibernate: Yes (support for multiple development models; Java first, mapping first, table first, Java/XDoclet first)
  • Hydrate: Yes - code generation used to generate basic bean interfaces and classes if you want to use them.
  • iBATIS DB Layer: No (by design, generally agree with the comment below)
  • Infobjects ObjectDRIVER: Yes
  • InterSystems Cache: Yes -- it is a fully object-relational DB, so you define the database "Classes" and it generates the Java Objects.
  • Jakarta ObjectRelationalBridge: Yes
  • Java Ultra-Lite Persistence (JULP): yes
  • JaxorFramework: Yes
  • JdoGenie: Yes (generates mappings from classes)
  • JDX: Yes
  • KodoJdo: Yes
  • LiDO: See XIC
  • Lychee: Yes, can generate java objects out of the XML mapping file.
  • O/R Broker: No thanks.
  • PowerMapJdo: Forward/ reverse engineering features
  • Signsoft intelliBO: Yes
  • SimpleOrm: Yes! The big feature of SimpleOrm is that these are actually the same thing due to its generalized design. A single source of truth.
  • SpadeSoft XJDO: Yes
  • Sql2java: Yes
  • The ProductivityEnvironmentForJava (PE:J): Yes
  • TopLink: Yes
  • VBSF: Yes
  • XIC: Yes
Comments: (who says this is a GoodThing? I don't want my DomainObject classes' source generated by some tool) Well, for O/R mapping you have to define somewhere the fields and how they're persisted. This usually at least consists of class, field names, and types. If you write the class and the mapping, you violate OnceAndOnlyOnce and DontRepeatYourself since the mapping file duplicates all the information that is contained in the class itself. The mapping gives you all the information you need to generate the object itself, so why not generate it? Why write code that you don't have to? There's a difference between a DomainObject and a DataAccessObject. DomainObjects have behavior-intensive methods that implement various responsibilities allocated to them from application requirements. Is the mapping tool going to generate the code for all my DomainObject's responsibilities? I doubt it. It probably generates only a simple class skeleton consisting of variable declarations and getters and setters - which I may not even want. And it probably can't preserve non-generated additions when the need arises to re-generate due to class shape or mapping changes. The DomainModel is the heart of the system - see http://domainlanguage.com/book.html - and can be written and tested before any persistence-related code is even written. Plus, what happens if you want to switch persistence technologies, such that your mapping and the tool that generates it becomes irrelevant? Many of the problems you describe relate to PassiveCodeGeneration and not ActiveCodeGeneration (regenerate at every build, NEVER MODIFY). There are ways to effectively merge business logic and generated objects. Basically it boils down to inheritance or composition, either one is effective. This is often called a the MartiniGlassArchitecture? b/c it allows you to seamlessly (ThereIsNoSuchThingAsSeamless) merge business and generated data logic into one unified DomainModel. Any tool, whether a language or a code generator, (Java and CeeSharp can also be viewed as code generators) can become obsolete. Evaluate your risks accordingly. Preferably, find an open source solution, get write access, then make sure it doesn't become obsolete. ;) Note that this problem can be side-stepped if you're using a language with decent RuntimeReflection?, like RubyLanguage, PythonLanguage, or SmalltalkLanguage. -- francis 16. Supports Composite Primary Keys
  • Abra: No (We think that primary keys should be unique DB ids not related to any business specification)
  • BasicWebLib - YES
  • Castor: Yes
  • CayenneFramework: Yes
  • CocoBase: Yes
  • DataBind: Yes
  • EdgeXtend: Yes
  • EnterpriseObjectsFramework: Yes
  • Expresso: Yes
  • FrontierSuite? for J2EE & J2SE: Yes
  • FrontierSuite? for JDO: Yes
  • Hibernate: Yes (separate primary key class, or "embedded" key as subset of object properties)
  • Hydrate: Yes, including keys of keys.
  • iBATIS DB Layer - YES (for foreign key relationships as well)
  • Infobjects ObjectDRIVER: Yes
  • InterSystems Cache: All objects have a unique Object ID (OID), but you can override these and create your own keys if you are dealing with relational tables.
  • Jakarta ObjectRelationalBridge: Yes
  • Java Ultra-Lite Persistence (JULP): yes
  • JaxorFramework: Yes
  • JdoGenie: Yes
  • JDX: Yes
  • KodoJdo: Yes
  • LiDO: See XIC
  • Lychee: No
  • O/R Broker: Yes
  • PowerMapJdo: Advanced support for mapped, composite, hybrid keys
  • Signsoft intelliBO: Yes
  • SimpleOrm: Yes
  • SpadeSoft XJDO: Yes
  • Sql2java: No (we focus on simplicity)
  • The ProductivityEnvironmentForJava (PE:J): Yes
  • TopLink: Yes
  • VBSF: Yes
  • XIC: Yes
17. Aggregate Mappings - Single field maps to multiple fields in database. http://martinfowler.com/eaaCatalog/embeddedValue.html 18. Supports both many to many and one to many associations 19. Supports collections of Strings, Integers, Dates, etc 20. Supports inheritance / polymorphic queries
  • Abra: Yes (but stores only leaf classes)
  • BasicWebLib - YES
  • Castor: No
  • CayenneFramework: Yes
  • CocoBase: Yes
  • DataBind: ?
  • EdgeXtend: Yes
  • EnterpriseObjectsFramework: Yes, three different models: single table, vertical and horizontal mapping. Supports "deep" fetches on super entities.
  • Expresso: ?
  • FrontierSuite? for J2EE & J2SE: Yes. All three mapping models - Vertical, Horizontal and Collapsed mapping.
  • FrontierSuite? for JDO: Yes. All three mapping models - Vertical, Horizontal and Collapsed mapping.
  • Hibernate: Yes (all three mapping strategies: table-per-hierarchy, table-per-concrete-class, table-per-subclass)
  • Hydrate: Yes
  • iBATIS DB Layer - NO
  • Infobjects ObjectDRIVER: Yes
  • InterSystems Cache: ?
  • Jakarta ObjectRelationalBridge: Yes
  • Java Ultra-Lite Persistence (JULP): yes
  • JaxorFramework: Yes
  • JdoGenie: Yes
  • JDX: Yes
  • KodoJdo: Yes
  • LiDO: See XIC
  • Lychee: No
  • O/R Broker: Yes, polymorphic queries are possible through the template languages, of which Velocity and FreeMarker are currently supported.
  • PowerMapJdo: Advanced support, query on extent, advanced union processing
  • Signsoft intelliBO: Yes
  • SimpleOrm: Depends what is really meant.
  • SpadeSoft XJDO: Yes
  • Sql2java: ?
  • The ProductivityEnvironmentForJava (PE:J): Yes
  • TopLink: Yes
  • VBSF: Yes
  • XIC: Yes
21. Supports one to one associations 22. Can fetch associated objects using SQL outer joins 23. Support for optimistic locking / versioning
  • Abra: Yes
  • BasicWebLib - NO
  • Castor: Yes (uses timestamping)
  • CayenneFramework: Yes
  • CocoBase: Yes
  • DataBind: No
  • EdgeXtend: Yes
  • EnterpriseObjectsFramework: Yes, automatic field-level locking using snapshotting.
  • Expresso: ?
  • FrontierSuite? for J2EE & J2SE: Yes
  • FrontierSuite? for JDO: Yes
  • Hibernate: Yes (version numbers or timestamps)
  • Hydrate: Manual
  • iBATIS DB Layer: Yes (manually coded)
  • Infobjects ObjectDRIVER: Yes
  • InterSystems Cache: ?
  • Jakarta ObjectRelationalBridge: Yes (version numbers or timestamps)
  • Java Ultra-Lite Persistence (JULP): yes
  • JaxorFramework: Yes (any combination of version numbers, timestamps, primary key, or any other field)
  • JdoGenie: Yes (version number, timestamp, original value in where clause etc)
  • JDX: Yes
  • KodoJdo: Yes (version number, timestamp, state image, custom)
  • LiDO: See XIC
  • Lychee: No
  • O/R Broker: Yes.
  • PowerMapJdo: Advanced support, incl transparent integration
  • Signsoft intelliBO: Yes
  • SimpleOrm: Yes. (This is essential for HTTP work.) 
  * SpadeSoft XJDO: Yes (version numbers, timestamp, user defined versioning)
  • Sql2java: Yes (manually coded)
  • The ProductivityEnvironmentForJava (PE:J): Yes
  • TopLink: Yes i) version numbers ii) timestamps iii) field-locking on any of AllFields?, ChangedOnlyFields? or UserDefinedGroupOfFields?
  • VBSF: Yes
  • XIC: Yes
24. Support for Unit of work / object level transactions
  • Abra: Yes
  • BasicWebLib - NO
  • Castor: Yes
  • CayenneFramework: Cayenne implements something called DataContext? for both editing and fetching - this is the same thing but is much more usable then UOW
  • CocoBase: Yes
  • DataBind: No
  • EdgeXtend: Yes
  • EnterpriseObjectsFramework: Yes
  • Expresso: Yes
  • FrontierSuite? for J2EE & J2SE: Yes
  • FrontierSuite? for JDO: Yes
  • Hibernate: Yes
  • Hydrate: Basic
  • iBATIS DB Layer - NO (supports both local and global transactions, but not object level)
  • Infobjects ObjectDRIVER: Yes
  • InterSystems Cache: ?
  • Jakarta ObjectRelationalBridge: Yes
  • Java Ultra-Lite Persistence (JULP): yes(UOW)
  • JaxorFramework: Yes (Default implementation and Pluggable API)
  • JdoGenie: Yes
  • JDX: No UOW but sophisticated transaction support including object level transactions
  • KodoJdo: Yes
  • LiDO: See XIC
  • Lychee: No, relies on database/container transactions.
  • O/R Broker: No, but supports JDBC transactions.
  • PowerMapJdo: Yes
  • Signsoft intelliBO: Yes
  • SimpleOrm: Yes 
  * SpadeSoft XJDO: Yes
25. Providing a SUN JDO compliant API 26. Providing an ODMG compliant API 27. Requires "extra" database tables holding locks, metadata, etc.
  • Abra: No
  • BasicWebLib: No
  • Castor: No
  • CayenneFramework: For automated primary key generation only.
  • CocoBase: No
  • DataBind: ?
  • EdgeXtend: No
  • EnterpriseObjectsFramework: No
  • Expresso: No
  • FrontierSuite? for J2EE & J2SE: No
  • FrontierSuite? for JDO: No
  • Hibernate: No (Only one of the key generation strategies requires it)
  • Hydrate: No
  • iBATIS DB Layer: No
  • Infobjects ObjectDRIVER: No
  • Jakarta ObjectRelationalBridge: No (only for a certain sequence number strategy and other special features)
  • Java Ultra-Lite Persistence (JULP): No
  • JaxorFramework: No
  • JdoGenie: For automated primary key generation only.
  • JDX: Optional
  • KodoJdo: No
  • LiDO: See XIC
  • Lychee: No
  • O/R Broker: No.
  • PowerMapJdo: Advanced transparent integration features, for seamless integration w existing and concurrent apps
  • Signsoft intelliBO: No
  • SimpleOrm: No, but one should use Postgre/Oracle sequence objects when generating unique keys.
  • SpadeSoft XJDO: No
  • Sql2java: No
  • The ProductivityEnvironmentForJava (PE:J): For auto-generated Primary Keys (for support of Datastore Identity in JDO)
  • TopLink: No
  • VBSF: No
  • XIC: Yes
28. Supports multiservers (clustering) and simultaneous access by other applications without loss of transaction integrity
  • Abra: Yes
  • BasicWebLib - NO
  • Castor: ?
  • CayenneFramework: Yes, via JGroups and JMS
  • CocoBase: ?
  • DataBind: No
  • EdgeXtend: Yes
  • EnterpriseObjectsFramework: Yes (With JMS based distributed caching sync on choosen entities only)
  • Expresso: Working on
  • FrontierSuite? for J2EE & J2SE: Yes (With JMS/Multicast based distributed caching)
  • FrontierSuite? for JDO: Yes (With JMS/Multicast based distributed caching)
  • Hibernate: Yes (including clustered cache)
  • Hydrate: With a transaction server.
  • iBATIS DB Layer: Yes
  • Infobjects ObjectDRIVER: Yes
  • InterSystems Cache: ?
  • Jakarta ObjectRelationalBridge: Yes
  • Java Ultra-Lite Persistence (JULP): no
  • JaxorFramework: Yes
  • JdoGenie: Yes (pluggable cache API)
  • JDX: Yes (using pessimistic locking)
  • KodoJdo: Yes
  • LiDO: See XIC
  • Lychee: Yes, due to not using any object caching.
  • O/R Broker: Yes
  • PowerMapJdo: Yes, focus on database integration and concurrency w existing systems
  • Signsoft intelliBO: Yes (JMS, TCP, ...)
  • SimpleOrm: No, not simple (except via DB).
  • SpadeSoft XJDO: Yes (Very high performance)
  • Sql2java: No
  • The ProductivityEnvironmentForJava (PE:J): Yes
  • TopLink: Yes (distributed cache synchronization included - via RMI/IIOP, JMS, role-your-own)
  • VBSF: Yes (by by-passing cache or refreshing cache from db, future cache synchronization mechanism planned)
  • XIC: Yes
29. Requires code generation / bytecode processing
  • Abra: Yes
  • BasicWebLib - NO (optional for certain features)
  • Castor: No
  • CayenneFramework: No, everything is POJO
  • CocoBase: No
  • DataBind: No
  • EdgeXtend: Yes
  • EnterpriseObjectsFramework: No
  • Expresso: No
  • FrontierSuite? for J2EE & J2SE: Yes
  • FrontierSuite? for JDO: Yes
  • Hibernate: Yes, but at runtime, not buildtime
  • Hydrate: Yes, buildtime for performance.
  • iBATIS DB Layer - NO (but optional for transparent performance optimization)
  • Infobjects ObjectDRIVER: No
  • Jakarta ObjectRelationalBridge: No for kernel and ODMG API, Yes for JDO Api
  • Java Ultra-Lite Persistence (JULP): no
  • JaxorFramework: Yes
  • JdoGenie: Yes (JDO bytecode enhancement)
  • JDX: No
  • KodoJdo: Yes
  • LiDO: See XIC
  • Lychee: No
  • O/R Broker: No.
  • PowerMapJdo: Yes, high performance data transfer
  • Signsoft intelliBO: Yes
  • SimpleOrm: Absolutely not. 
  * SpadeSoft XJDO: Yes (Built in enhancer or any standard JDO enhancer)
  • Sql2java: Yes, it generates java code very readable via javadoc
  • The ProductivityEnvironmentForJava (PE:J): Only JDO vendor that provides source-code enhancement so users can see the JDO enhancements for themselves.
  • TopLink: No
  • VBSF: No
  • XIC: Yes, JDO standard enhancement
30. Requires RuntimeReflection? 31. Query Caching - Built-in support (developer writes no code). The following two identical queries will hit the database only once. The second time cached results will be returned. Address address = AddressFinder.selectByPrimaryKey(new Long(1)); assertTrue(address == AddressFinder.selectByPrimaryKey(new Long(1)));
  • Abra: Yes (also if lookup is by OID, or done with query set)
  • BasicWebLib - NO
  • Castor: Yes (Persistent instance caching: count-limited | time-limited | unlimited)
  • CayenneFramework: ?
  • CocoBase: Yes. Also supports integration with 3rd party caching software.
  • DataBind: No
  • EdgeXtend: No, but previously queried objects are cached in memory and provides cache-only queries
  • EnterpriseObjectsFramework: Yes, if you want to
  • Expresso: ?
  • FrontierSuite? for J2EE & J2SE: Yes
  • FrontierSuite? for JDO: Yes
  • Hibernate: Yes. Hibernate Dual Layer Cache Architecture - session level + JVM level caching + query result set caching (also PreparedStatement caching)
  • Hydrate: Yes
  • iBATIS DB Layer - YES (JVM level + PreparedStatement cache)
  • Infobjects ObjectDRIVER: Yes
  • InterSystems Cache: ?
  • Jakarta ObjectRelationalBridge: Yes (PreparedStatement caching and persistent instance caching)
  • Java Ultra-Lite Persistence (JULP): yes
  • JaxorFramework: Yes (Default Implementation and Pluggable API)
  • JdoGenie: Yes (for primary key lookup and JDOQL queries)
  • JDX: Yes
  • KodoJdo: Yes
  • LiDO: See XIC
  • Lychee: No (Was intentionally designed not to use object caching to avoid hassle associated with it)
  • O/R Broker: No. Is not threadsafe for mutable objects. That's better left to RDBMS, JDBC, or DAO layer.
  • PowerMapJdo: Yes.
  • Signsoft intelliBO: Yes (primary key based, in memory, ...)
  • SimpleOrm: Yes. Again this is pretty much mandatory.
  • SpadeSoft XJDO: Yes
  • Sql2java: Yes (manually coded)
  • The ProductivityEnvironmentForJava (PE:J): Yes
  • TopLink: Yes; primary key-based caching, prepared-statement caching, partial but ineffective support for caching of results from arbitrary user queries; maintains transactional integrity by conforming the results against current unit-of-work state; in-memory querying.
  • VBSF: Yes
  • XIC: Yes
32. Supports sequences and identity/autoincrement columns for primary key generation (Not using the incorrect SELECT MAX method!)
  • Abra: Yes.
  • BasicWebLib - YES
  • Castor: Yes. (also has hi/lo, uuid, sequence, etc)
  • CayenneFramework: sequences and a few other strategies are supported
  • CocoBase: ?
  • DataBind: ?
  • EdgeXtend: Yes
  • EnterpriseObjectsFramework: Yes, including standalone unique sequence number (aka. not sql sequence generated)
  • Expresso: ?
  • FrontierSuite? for J2EE & J2SE: Yes
  • FrontierSuite? for JDO: Yes
  • Hibernate: Yes. both sequences and identity columns (also hi/lo, uuid, etc. as well as user defined strategies)
  • Hydrate: Identity columns
  • iBATIS DB Layer - YES (supports it, but not automated)
  • Infobjects ObjectDRIVER: Yes
  • InterSystems Cache: ?
  • Jakarta ObjectRelationalBridge: Yes. (also has hi/lo, uuid, and user defined strategies)
  • Java Ultra-Lite Persistence (JULP): yes
  • JaxorFramework: ?
  • JdoGenie: Yes
  • JDX: Yes
  • KodoJdo: Yes
  • LiDO: See XIC
  • Lychee: Yes, with custom implementation of IdProvider? interface.
  • O/R Broker: Yes, if RDBMS supports it.
  • PowerMapJdo: Yes
  • Signsoft intelliBO: Yes
  • SimpleOrm: Yes, and safely.
  • SpadeSoft XJDO: Yes
  • Sql2java: Yes
  • The ProductivityEnvironmentForJava (PE:J): Yes
  • TopLink: Yes - auto-generated Primary Keys can be derived from a table; alternatively, PK's can be derived from an IDENTITY column (SYBASE, MS-SQLServer, etc) or Oracle sequences.
  • VBSF: Yes
  • XIC: Yes
33. Supports ternary associations The "ternary relationship" entries look a bit misleading. Please double check that, and provide documentation. For example TopLink and ObjectRelationalBridge provide no easily accessible official documentation of how they support such a feature (if indeed they support), or if they provide that they keep it very well hidden. Workarounds do not qualify as support, I'd expect that the same documentation that provides extended discussion of One to One, One To Many and Many to Many (usually mapped to first class objects in the API, and first class entities in the XML configuration file ) should provide a clarifying example/discussion of n-ary relationship concept, backed by the corresponding entry in the API or XML. For whatever reason ObjectRelationalMapping makes for lots of passion, witness the inordinate amount of open source projects, a sign that a great deal of good developers preferred a "roll your own" solution. So we need to try to keep this discussion relatively to the level of a little more than marketing material checkboxes. 34. Supports mapping of one class to multiple tables 
 Comments: Any comments on this? Is this really a useful thing to do? If the tables are badly designed, fix them!
I believe why this question can is solve by convenient UML diagram
We think this is a Bad Thing: http://www.hibernate.org/Documentation/Delegate
Sometimes legacy databases leave you no choice.

I believe that for a general purpose persistence framework, this type of support is absolutely critical. The reason is that in many development shops, different people control the object and data models. In the real world, either or both could be well designed or poorly designed. Either or both could be a legacy model, or new. 35. Supports mapping of multiple classes to one table 36. Supports persistence of properties through private fields 37. Supports persistence of properties through accessors (get/set methods) Other questions 38. Supports disconnected operations: Populate objects from database, disconnect, create/remove/modify objects (on client, another JVM) and apply changes to database (much) later
  • Hibernate: yes
  • Hydrate: yes
  • Java Ultra-Lite Persistence (JULP): yes
  • JDX: Yes
  • KodoJdo: Yes
  • Lychee: Yes, totally avoids the hassle of objects being attached/detached to/from sessions.
  • O/R Broker: Yes.
  • SpadeSoft XJDO: Yes (supporting JDO 2.0 attach/detach architecture)
  • XIC: Yes
39. Supports logging all the executed SQL statements in a SQL file ? 40. Supports an API allowing to invalidate part of the cache (for example when the database is updated directly)?
  • CayenneFramework: Yes
  • EnterpriseObjectsFramework: Yes (per instance or per entity, including on a time basis)
  • Hibernate: yes (per instance or per class)
  • JDX: Yes (per instance or per class or for all classes)
  • KodoJdo: Yes
  • Lychee: No (Does not have cache. Was intentionally designed not to use object caching to avoid hassle associated with it)
  • O/R Broker: No, caching is not supported. Better done in DAO layer.
  • SpadeSoft XJDO: Yes
  • Sql2java: Yes
  • XIC: Yes
41. Supports massive updates (with batch and transaction size tuning)?
  • CayenneFramework: Yes In fact update batching is built into Cayenne
  • EnterpriseObjectsFramework: Yes
  • Hydrate: Yes
  • JDX: Yes (size depends upon the predicate)
  • KodoJdo: Yes
  • Lychee: Yes, full batched statements support (supports batching of inserts, updates and even selects)
  • O/R Broker: Yes.
  • SpadeSoft XJDO: Yes
  • Sql2java: No
  • XIC: Yes
42. Supports Date/Timestamp mapping with correct time zone? 43. Supports mapping of immutable objects?
  • KodoJdo: Yes
  • O/R Broker: Yes
  • XIC: Yes
Tags :

Subscribe by Email

Follow Updates Articles from This Blog via Email

Được đăng bởi vào lúc
Nhãn:

5 Comments

avatar
Anonymous July 25, 2007 at 6:44 AM

Some slight corrections in regards to Signsoft intelliBO:

- The actual version is 4.1, available on the website
- There exist a "free as in beer" version (community edition)
- There is support for pt. 38 (disconnected operations). Signsoft intelliBO supports the attach/detach mechanism as specified in JDO 2.
- there are some slight changes in the list of supported databases: the current list is (beside of generic JDBC support) IBM DB/2 UDB, Derby , H2 Database, HSQL, Informix, Ingres, McKoi, MS SQL, MySQL, Oracle (9, 10), PostgresQL, Sybase

Reply Delete
avatar
Unknown September 7, 2007 at 5:37 AM

Hi

This looks like a copy paste of wikipedia and http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison

Where is your added value ?

Reply Delete
avatar
Enterprise Mobile Apps July 30, 2012 at 11:59 PM

Your information is really superb..

OFS builds class enterprise mobile apps for companies to equip their workforce with the latest ipad, iphone, Android, Blackberry and Windows mobile technologies. OFS has more than 300 mobile application development specialists in Atlanta, Philadelphia, Washington DC, New York and Chennai.

Reply Delete
avatar
darichkid March 9, 2013 at 12:20 AM

TrungNEMO

Here is an ORM that works with Microsoft Access
https://www.kellermansoftware.com/p-47-net-data-access-layer.aspx

Reply Delete
Post a Comment
Subscribe to: Post Comments (Atom)