| 1.1.1. | What is Kodo? |
Kodo is an implementation of the Java Data Objects (JDO) standard that enables developers to transparently access persistent data stores via the Java programming language. | |
| 1.1.2. | What is JDO? |
JDO stands for Java Data Objects, and is a standard written by Sun Microsystems to provide transparent access to a variety of datastores, from relational databases to object databases to plain files. A good introduction to JDO can be found at Part II, “Java Data Objects”. | |
| 1.1.3. | Is Kodo a database? |
No. Kodo provides a means to access an existing database. | |
| 1.1.4. | Is Kodo an application server? |
No, although Kodo can integrate seamlessly with any J2EE 1.3 compliant application server. | |
| 1.1.5. | Does Kodo require an application server? |
No. Kodo can be run without any external managed environment, although it can also be used from within an EJB container, a servlet, or any other managed environment that is J2EE compliant. | |
| 1.1.6. | What is the difference between JDO and JDBC? |
Java Database Connectivity (JDBC) is an API that allows developers to directly access a relational database. JDO is a datastore-agnostic approach that aims to reduce the complexity of designing persistent applications, and is not constrained to any particular type of datastore. Kodo JDO utilizes JDBC to access the relational database. | |
| 1.1.7. | What is the difference between JDO and EJB? |
Enterprise Java Beans are managed distributed components that handle application-level security and automatic transaction demarcation. In contrast, JDO simply provides a transparent means to access a datastore. EJB and JDO are complimentary technologies; developers can to write their EJBs to utilize the transparent persistence provided by JDO, rather than being limited to the restrictions of using the built-in CMP persistence or vendor-specific application server extensions. | |
| 1.1.8. | Do I need to know SQL to use Kodo? |
No. Kodo JDO completely shields the developer from needing to write or debug SQL statements, although it does provide advanced extensions for developers who are familiar with SQL to create new mappings. | |
| 1.1.9. | What standards does Kodo conform to? |
Kodo conforms to the Java Data Objects 1.0.1 specification. Additionally, various parts of Kodo confirm to other standards and specifications, including XML, JTA, JCA, JNDI, JDBC, EJB, JMX, XA, and J2EE. | |
| 1.1.10. | What version of Java does Kodo require? |
Kodo requires JDK 1.2.2 or higher to run. Additionally, Kodo provides some additional features for Java 5 development, including support for persisting enum fields and full use of generics information (if present) in place of JDO metadata for collection and map element type data. These are only accessible when using Kodo in conjunction with a Java 5 runtime environment. | |
| 1.1.11. | I have problems or questions about Kodo. Where can I go for help? |
The SolarMetric developer community can be accessed from http://solarmetric.com/Support/Newsgroups. Other support resources can be accessed at http://solarmetric.com/Support. Also, if you have a maintenance and technical support contract with SolarMetric, you can e-mail questions to jdosupport@solarmetric.com. | |
| 1.1.12. | I think I found a bug in Kodo. Where do I report it? |
The first thing you should do is search for any existing bugs in SolarMetric's bug tracking system: http://bugzilla.solarmetric.com. It is often the case that someone else may have already reported the bug, and a possible solution or workaround can be found in the existing bug report. If you are confident that your issue has not already been reported, you can report it to SolarMetric by posting on the community newsgroups or sending mail to jdosupport@solarmetric.com. |