Discussions

News: Class Persistence Object (CPO) artifacts uploaded to SourceForge

  1. Class Persistence Object (CPO) is a java api and utility program for Object to JDBC Mapping (OJM). Unlike Object Relational Mapping (ORM) technologies and the java persistence api, CPO is designed to allow you to fully utilize the native sql and functionality of your database. http://cpo.sourceforge.net CPO is a Class Persistence interface for storing objects in different datasources. The interface is currently implemented for JDBC datasources but can be expanded to XML, Flat File, RMS, LDAP, etc. The jdbc implementation of CPO provides an OJM api and utility. OJM differs from ORM and the Java Persistence API (JPA) in that it lets the developer, database admin, or data architect be responsible for the design of the database. The developer uses CPO to map plain old java objects (POJOs) to JDBC calls which execute native sql against the database. This provides the most flexibility when accessing legacy databases where the developers may have little control over the DBMS. This also allows you to use all of the syntax, functions, data types, and stored procedures available in the database. CPO has been tested using Oracle, MySql, and HSqlDB. We have been using CPO for over three years and thought that it may be useful to others as well.

    Threaded Messages (6)

  2. Is there any advantage over iBatis?[ Go to top ]

    Can you provide an objective comparison with iBatis?
  3. Objective comparison[ Go to top ]

    Going through the iBatis documentation here are some of the differences: iBatis has Caching, CPO does not iBatis supports Complex Objects, CPO does not. CPO is therefore always lazy loading as it is up to the programmer to decide when and where to load the child objects. iBatis supports Global Transactions (JTA), CPO does not CPO's dynamic where statement is defined at run-time which allows user input to dictate exactly what attributes are going to be used in the where clause. The dynamic nature does not need to be pre-defined in a config file. CPO's configuration is captured in a database and provides a utility for updating the configuration. CPO allows you to define a Meta Datasource, a Read Datasource and a write datasource. The separate Meta Datasource allows you to have a separate datasource for configuration. Separate Reads and writes allow you to identify specific database servers within a cluster or group of databases to handle reads and writes from. CPO's built-in datasource provides for prepared statement caching as well as connection pooling. Because you specify your java bean mappings for a specific datasource, CPO is an excellent ETL tool. The same java bean can be mapped to different databases and queries and both sets of mappings can be accessed from the same program. This would allow you to perform transforming data from a transaction database to a reporting/warehouse database or even from Oracle to MySQL.
  4. Why use this??[ Go to top ]

    Why should I use this? A simple Tablerow mapper pattern and some basic java code is enough to be able to use plain sql in an easy maintainable and usable manner. If that is not enough there are enough other (iBatis) implementations. Kind regards, Marc
  5. Re: Objective comparison[ Go to top ]

    Because you specify your java bean mappings for a specific datasource, CPO is an excellent ETL tool. The same java bean can be mapped to different databases and queries and both sets of mappings can be accessed from the same program. This would allow you to perform transforming data from a transaction database to a reporting/warehouse database or even from Oracle to MySQL.
    Well, JDO does the same detaching from one PersistenceManager and attaching to another. Beware that the two PM may map to totally different storage technologies. You can easily read object from a relational database and store in a DB4O database or in a LDAP, or XML file, or Excel file and viceversa. Using exactly the same API and the same query language. @See DataNucleus at http://www.datanucleus.org Guido
  6. Re: Objective comparison[ Go to top ]

    CPO's dynamic where statement is defined at run-time which allows user input to dictate exactly what attributes are going to be used in the where clause. The dynamic nature does not need to be pre-defined in a config file.
    Defining queries in separate files (like iBatis) is, IMHO, a good thing, because queries are centralised at a single place (better maintainability), and can be reviewed by a DBA without auditing your Java code. If you need dynamic where clause, there is a criteria API, in iBatis ("dynamic mapped statement"), and this is also defined in the separate file.
    CPO's configuration is captured in a database and provides a utility for updating the configuration. CPO allows you to define a Meta Datasource, a Read Datasource and a write datasource. The separate Meta Datasource allows you to have a separate datasource for configuration. Separate Reads and writes allow you to identify specific database servers within a cluster or group of databases to handle reads and writes from.
    Not sure about configuration, I don't think there is something like that in iBatis (there might be use case where this is valuable). But you can have and define different configuration and mapping to manage you data ("SqlMapClient" object).
    CPO's built-in datasource provides for prepared statement caching as well as connection pooling.
    iBatis does not really provide a datasource; it uses an external one, the main reason being that it is (I think) beyond the project's goal (other vendors/projects provide very good datasources, it is the approach of iBatis sqlmap architects).
    Because you specify your java bean mappings for a specific datasource, CPO is an excellent ETL tool. The same java bean can be mapped to different databases and queries and both sets of mappings can be accessed from the same program. This would allow you to perform transforming data from a transaction database to a reporting/warehouse database or even from Oracle to MySQL.
    You can do something like that in iBatis (different SqlMapClient at the same time). CPO and iBatis look similar.
    I think iBatis is a lot more mature, provides cleaner design and more functionalities for now. Cyril
  7. Feature set sounds nice[ Go to top ]

    Looks like a nice project. However, I don't see anything wrt caching of objects, i.e. how do you speed up CPO? We are currently using JDO and, yes, for performance reasons we sometimes have to go the bare metal and use database-specific SQL. However, our JDO vendor supports a nifty second level cache. It tries hard to avoid loading objects from the database and uses on-the-fly created state objects, to hold the state of your POJOs. When you request the same POJOs in a new transaction, it will recreate them using the state objects (if it can determine, that those objects have not been changed in the database)