• Home
• News
• Empire-db
  • The Empire DAO-
    pattern
  • Handling data and metadata
  • What's wrong with Hibernate and JPA
  • The principle of
    string-free coding
  • FAQ
• Empire-db and Struts2
  • Forms and controls
  • Rendering and parsing
  • Input controls
• Downloads
  • Previous releases
  • License
• Documentation
  • Empire-db class
    overview
  • Tutorial
  • Getting started
  • Reverse Engineering
  • API
• Community
  • Mailing lists
  • Source code
  • Ticketing & Wiki
  • Contributors
• About Apache
  • Apache home 
  • Sponsorship 
  • Foundation thanks 
  • Security 
• License 

Empire-db » Handling data and metadata Download

Handling data and metadata

Many persistence solutions are primarily designed for working with JavaBeans representing full database entities. For foreign key relationships the referenced objects are automatically loaded when needed to build an object hierarchy that directly reflects the data model. However in many cases it is neither desirable nor necessary to work with full entities. Relational databases are extremely efficient when it comes to combining individual columns joined and gathered from various tables, sometimes even transformed or calculated. In most cases this result is used merely for display and selection purposes and thus does not require updating the individual rows.

With Empire-db both working with full database entities and working with complex and varying query results are equally well supported. Consequently Empire-db distinguishes between read only data and full entity records which are updateable. This however does not only affect access to data but also metadata access, since for updateable data more meta information is required. Hence the distinction is also made on the metadata side distinguishing a column expression for read only data and a full column for updateable data.

For implementing this behavior Empire-db offers four interfaces: two each for data and metadata access and two each for read only and updatable data. Note that these interfaces are not limited to relational databases and might as well be used for other data sources. The following matrix shows the four interfaces and their relationships:

In Empire-db terms the Record is the thing that holds the data and the Column the thing that holds the metadata. For data access Empire-db distinguishes between record data which is read only and possibly the result of any SQL query and a full entity record which is returned by a Data Access Object (i.e. a table or a view). Accordingly it distinguishes between a column expression which provides display metadata for displaying a value and a full featured column which also provides information required for data input.

When working with Empire-db you will notice the following classes implementing these interfaces:

Interface	Implementations provided by Empire-db
RecordData	DBRecordData(abstract), DBReader
Record	DBRecord
ColumnExpr	DBColumnExpr (abstract), DBAliasExpr, DBConcatExpr, DBFuncExpr, etc...
Column	DBColumn (abstract), DBTableColumn, DBViewColumn

Besides those implementations you are free to use these interfaces for your own objects and provide your own implementation.

---