1.2. Database
Prev | Chapter 1. Kodo JPA/JDO Frequently Asked Questions | Next

## 1.2. Database

1.2.1. Does Kodo require a database to function?
1.2.2. What databases does Kodo support?
1.2.3. What additional software do I need to use Kodo with my database?
1.2.4. Where can I find the JDBC driver for my application?
1.2.5. What is the best JDBC driver to use for my application?
1.2.6. What version of JDBC does Kodo use?
1.2.7. Can Kodo integrate with a legacy database schema?
1.2.8. I am designing a persistent model from scratch and don't want to deal with creating a database schema. Can Kodo generate a schema for me?
1.2.9. I have both an existing object model and an existing database schema. Can I use Kodo without making changes to either?
1.2.10. Can Kodo generate the DDL for my database?
1.2.11. Can a Kodo run against multiple databases?
1.2.12. Is there any limit to the number of rows Kodo can handle?
1.2.13. Can Kodo work with foreign keys?
1.2.14. How can I change what schema Kodo is using?
1.2.15. What do I have to do when using an external DataSource?
1.2.16. How has the schema tool changed since version 2.x?

1.2.1. | Does Kodo require a database to function?
| Kodo does require an existing database against which to operate. However, Kodo ships with a small, open-source, pure-java database called Hypersonic that can be used for development without requiring an existing database installation.
1.2.2. | What databases does Kodo support?
| Kodo has built-in support for all the major databases, including Oracle, Microsoft SQL Server, DB2, Sybase, and Informix. In addition, Kodo provides APIs that allow the developer to adapt Kodo to work with any other database that provides a JDBC-compiant driver. A full list of the supported databases can be found at Appendix 4, Supported Databases.
1.2.3. | What additional software do I need to use Kodo with my database?
| Kodo requires the Java Development Kit. Additionally, if you will be accessing a database other than Hypersonic, Kodo requires a JDBC driver that can communicate with your database. All other libraries needed by Kodo are provided in the Kodo distribution. A list of all the libraries that Kodo requires and uses can be found at Appendix 7, Development and Runtime Libraries.
1.2.4. | Where can I find the JDBC driver for my application?
| JDBC drivers are typically obtained from the database vendor's web site. In addition, there are many third-party companies that provide JDBC drivers for various databases. For a comprehensive list of existing JDBC drivers, see the Sun JDBC driver database at: http://servlet.java.sun.com/products/jdbc/drivers.
1.2.5. | What is the best JDBC driver to use for my application?
| We do not usually endorse any specific JDBC driver for a particluar database. Provided the driver is truly JDBC compliant, it should work with Kodo without problems. Typically it is a good idea to first look at the JDBC driver that your database vendor provides, since these are often high-quality and free. An advantage of an object persistence API is that you can simply "drop in" a different JDBC driver version and change a few properties, and you can test your application without changing any code. This makes the process of profiling your application's performance with different JDBC drivers a very simple task.
1.2.6. | What version of JDBC does Kodo use?
| Kodo utilizes version 2.0 of the JDBC specification, and requires that a driver be JDBC 2.0 compliant. In addition, Kodo uses the JDBC 2 Standard Extensions, which are provided in the Kodo distribution.
1.2.7. | Can Kodo integrate with a legacy database schema?
| Certainly. Kodo provides a very flexible set of mapping options to be able to integrate your Java object model with almost any relational database schema. In addition, Kodo provides extensible APIs that allow the developer to create their own mappings for those non-standard relational constructs that may not be included with Kodo "out of the box". Furthermore, Kodo provides a reverse mapping tool, which allows developers to automatically generate a Java object model from an existing schema, which dramatically reduces the amount of time the developer needs to spend manually setting up the mappings. To get started with the reverse mapping tool, see ???, Section 2.3, “Reverse Mapping Tool Tutorial”.
1.2.8. | I am designing a persistent model from scratch and don't want to deal with creating a database schema. Can Kodo generate a schema for me?
| Yes. Kodo allows you to design your application in a object-centric fashion, and can automatically generate a consistent relational schema from your object model. This is ideal for developers who are designing a new application that does not need to integrate with an existing schema. See Section 7.1, “Forward Mapping”.
1.2.9. | I have both an existing object model and an existing database schema. Can I use Kodo without making changes to either?
| Probably. Kodo's mapping capabilities are quite flexible, and the Kodo mapping tools provide facilities to deal with this "meet-in-the-middle" scenario. See Section 7.3, “Meet-in-the-Middle Mapping” for a more detailed description.
1.2.10. | Can Kodo generate the DDL for my database?
| Yes. Kodo can either issue the DDL directly in order to create or update your database, or it can create a SQL script file. This can be done from the command line or using Ant. See Section 7.1.2, “Generating DDL SQL” for examples.
1.2.11. | Can a Kodo run against multiple databases?
| Yes. Kodo can operate simultaneously against an arbitrary number of databases at the same time. Utilizing XA transactions, you can even ensure transactional consistency across a hetergeneous set of databases when using container managed transactions.
1.2.12. | Is there any limit to the number of rows Kodo can handle?
| There is no limit to the size of table against Kodo can operate, nor is there any limit to the number of tables in the database. Kodo is used in applications that use databases ranging from just a few tables, to databases that have thousands of tables with millions of rows.
1.2.13. | Can Kodo work with foreign keys?
| Kodo can work with both deferred and non-deferred constraints. With non-deferred constraints, Kodo analyzes foreign key dependencies before executing SQL. With deferrable constraints, you should either make deferred the default or extend `DBDictionary`. to set deferred as the default for every connection.
1.2.14. | How can I change what schema Kodo is using?
| Kodo can be configured to look at a subset of schemas, assign a default schema to mapping information, and to ignore the schema altogether. The first is controlled by the Section 2.8.13, “kodo.jdbc.Schemas” option which enumerates the schemas to analyze. The other options are configured at the `DBDictionary` level with the `UseSchemaName` and `DefaultSchemaName` properties (see Section 4.4, “Database Support”).
1.2.15. | What do I have to do when using an external `DataSource`?
| While Kodo can handle external `DataSource`s, there are certain additional configuration options to be aware of. If your external `DataSource` automatically integrates with the global transaction (such as XA `DataSource`s), you should ensure that Kodo has access to a non-transactional `DataSource`: Section 4.2.1, “Managed and XA DataSources”
1.2.16. | How has the schema tool changed since version 2.x?
| The schema tool has been redesigned to only manage the schema through XML representations of the schema. The mapping tool now manages the mapping between your classes and database. The mapping tool can optionally use the schema tool to synchronize the database schema and create any missing database objects. For further information on the mapping tool, see Section 7.1, “Forward Mapping”.

Prev | Up | Next
Chapter 1. Kodo JPA/JDO Frequently Asked Questions | Home | 1.3. Programming with Kodo