Message-ID: <778246615.3167.1369363223000.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_3166_1372202364.1369363223000" ------=_Part_3166_1372202364.1369363223000 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
tapestry-model-hibernate (a submodule of tapestry-model) extensively use= s Hibernate as it's persistence layer. While you can provide a diff= erent "persistenceService" implementation, the only one provided = by Tynamo is a HibernatePersistenceService, which as the name implies, impl= ements a Hibernate based persistence mechanism. Hibernate is an ORM tool th= at maps your Java objects to a database schema.
By default, Tynamo uses in-memory H2 database, which means it's = super-simple to set up and the database only exists in-memory. H2 is unbeli= evably small and fast, evolves quickly and is nice to develop with, and eve= n nicer for running your db integration tests against. Because the start-up= cost is minimal, you always start from a clean slate and you know it works= no matter what the environment is.
With Hibernate it's very well possible and easy to use more than one typ= e of database since the switching cost is minimal - you just provide a diff= erent database configuration and off you go.
However, one potential issue that you want to be careful with using rese= rved words in the database, because Hibernate maps your entities directly t= o a database schema.
A simple example of what doesn't work is a property named "date&quo= t;, i.e. having getDate() operation in one of your entities. These are typi= cally easy to spot from the error logs when you start up your application a= fter adding a new entity. The theory is that by supporting (and testing wit= h) more databases you make your implementation stronger.
Typical scenarios for different database use cases are:
This is not a generic database guide, but a few words about the choices.= For development, your best bets are H2, HSQLDB, Derby or MySQL depending o= n your preferences and what you are used to. Most databases come with some = type of command-line interface but H2 has a great, built-in web interface f= or looking at the raw database results and executing raw SQL queries. If yo= u appreciate automating even the database setup for development, H2 and HSQ= LDB are easy to embed, and are especially useful when doing integration sys= tem with fully automated build systems.
Your production database of choice depends largely on your application t= ype and your deployment environment. For a small-scale prototyping, free or= open-source projects, HSLQDB, DERBY, MySQL and PostgreSQL are good choices= . If the database choice isn't up to you, you should check that Hibernate f= irst of all supports it and secondly, keep testing frequently that your dom= ain model works with the particular database even if you don't use it durin= g development. H2 is proven to work with millions of records without hick-u= ps (see H2's own performance comparisons).<= /p>
Your typical hibernate.properties for development should look something = like this:
For other database configurations (and required dependencies, check out = our Sample datab= ase configurations. Using hibernate.hbm2ddl.auto=3Dcreate-drop= causes the database to be created at the start-up and then deleted after u= se which might be advantageous in some cases, like for integration testing.= Hibernate also allows you specify hibernate.hbm2ddl.auto=3Dvalidate, which may make sense in a production environment, but notice that insta= ntiating the Hibernate related services would fail if you use validate<= /em> and Hibernate requires changes to be made in the database schema.
Back to Developing in= IDEs or continue to Cust= omizing pages------=_Part_3166_1372202364.1369363223000--