Empire-db » Frequently asked questions Download


How long has Empire-db been around and why have I never heard of it?

The conceptual design and first implementation of Empire-db was made in the year 2000 by ESTEAM Software. In the following years it has constantly improved and proven its superior capabilities in various database related projects. In summer 2007 ESTEAM Software decided that the solution was now mature enough to be released as an Open Source project under the name Empire-db.

What application is Empire-db suitable for?

We have used Empire-db for both Web and Rich-client applications as well as for interfaceless cronjobs and from information systems to data warehousing. The more extensively you need to use a relational database and the more data driven your application is the more suitable is Empire-db.

What Web application frameworks does Empire-db integrate with?

Conceptually you can use Empire-db with any Web application framework but there is a special – and we believe revolutionary – integration for the new Struts2 Web application framework offered by the Apache foundation. With what we call the Empire-Struts2-Extensions you can utilize all of Empire-db’s metadata capabilities through special HTML-Tags. We think that Web application development has never been more efficient and that separation of view and model has never been cleaner as with this solution.

Does Empire-db conform to the JPA standard?

No. The JPA standard is a least common denominator specification of object relational mapping (ORM). If Empire-db was yet another JPA implementation it could not offer any major benefits over existing solutions. We believe that only with a fundamentally different approach issues such as compile-time safety and metadata management can be addressed properly.

Does Empire-db handle connection pooling and object caching?

No. Empire-db is passive and leaves connection and transaction handling to you and your application container – thus leaving you in full control and requiring zero configuration. While object caching might be necessary for traditional ORM solutions, we think with the way Empire-db is designed there is no real need for it. Besides that, we feel that object caching in relational data persistence can be problematic.

How does Empire-db implement inserts, updates and optimistic locking?

Empire-db automatically keeps track of all changes on an entity by keeping a modification flag for each attribute. Thus only modified fields are inserted and updated in the database. Empire-db also keeps track of an entity's state, hence it automatically knows whether to perform an insert or an update operation. For optimistic locking Empire-db requires a timestamp field to be provided with the corresponding table, through which concurrent changes in the database are detected. This feature is optional but strongly recommended.

Can Empire-db generate arbitrary insert, update and delete statements?

Yes. The DBCommand object will let you generate SQL statements for either querying (select), updating, inserting or deleting data just as you'd write them, but entirely string-free only by using its unique API. This will make your code portable and you can easily run it on another DBMS just by selecting the corresponding driver.

Can Empire-db change the data model at runtime?

Yes. With Empire-db you can even change the data model dynamically at runtime by creating, altering or deleting objects like tables, views, relations or columns – provided that the driver supports this feature. Because of its dynamic beans you can use new and changed objects just as if they had existed like that at compile time. This is something you clearly can't do with traditional JavaBeans / POJOs.

Does Empire-db support DBMS specific SQL functions?

Yes, if supported by the driver. An example is the Oracle's "connect by prior" phrase which can be used to perform hierarchical queries. With an Oracle driver attached to your database you can cast your DBCommand object into a DBCommandOracle object. This will then provide the two additional methods connectByPrior() and startWith(). However this will make your code Oracle specific.