Data access

From ESEwiki

Data access is an important topic because it is one of the basis of enterprise systems reliability (data need to be saved and recovered).

Although most people think "database", it does not need be so. Databases are important enough, but plain files, property files or XML files are also valuable data storages (as long as one knows the trade-offs between performance, reliability, memory footprint, and so on).

ESE attempts to be back-end agnostic: that is, every kind of data should be accessed the same way. Therefore, accessing data stored in a database should not be different from reading data stored in an XML file, say. Of course there will be a difference ---but it must be minimum; that is, just specifying where your data is should be enough.

That is one of the basic concepts of EDC (Eiffel Data Connection): the url gives you the "address" where your data is stored, along with the protocol to use to access it (is it a database? a property file?)

Another important thing is that EDC is firstly object-oriented. There is currently no "SQL parser" or any standard data-centric query language. Why use another language when Eiffel does it all? You will see that using EDC, which totally blends in Eiffel, is at least as simple as learning yet another language^[1].

Contents 1 What makes EDC interesting? 2 Concepts 2.1 The driver 2.2 The connection 2.3 The queries 2.4 The result set 3 How is the data organized 4 More details about queries 5 Examples 6 Notes

What makes EDC interesting?

(i.e. what makes EDC more interesting than any SQL back-end?)

• Transparent storage of business objects. You have an object model and wonder how to save it in a database? Don't want to waste time creating an object-relational mapping? Just store your business objects!
• Not bound to SQL, or other relational databases; can have other storage back-ends such as XML files, object databases, or whatever you can think of. Create your own back-end!
• Object oriented. Today that's what programmers look for. Leverage all the power of the Eiffel language! Forget the ugly SQL language!

Concepts

There are four concepts in EDC: the driver which allows access to one kind of data, the connection which connects to one particular data source, the queries which allows to read or modify the data, and the result set which is the result of some read query.

The driver

A driver understands one data protocol. It means that a driver can manage one (and only one) sort of data. It is not a data access itself, because that's the role of the connection (below). But it creates connections that read and write data using that protocol.

There are (or will be) a few drivers for EDC:

• XML: that's the "100% SmartEiffel" driver, that uses the internal XML object representation of SmartEiffel for data storage and recovery (technically, it uses the STORABLE facility of vanilla SmartEiffel).
• GDA: that's the GNOME database driver. It understands all kinds of databases: MySQL, Posgresql, Oracle, Sybase, and so on. Even an XML protocol is included.
• JDBC: that's the Java database driver. When using the compile_to_jvm SmartEiffel compiler, one can access databases through the standard Java API.
• Log: allows to write queries in a log file (in SQL format); it then passes the queries to another driver.

Currently only the XML and Log drivers are available.

The connection

A connection is a real access point to some data. The difference between a driver and a connection is the same as the difference between "a file" and "the README.txt file", or the difference between a class and an object. Drivers implement a protocol, while connections use a protocol to access to real data.

A connection also manages sessions.

A session is a temporary connection state when changes can happen that are not visible to others. It is initialized from the permanent storage, either at the connection creation or when the previous one is closed. A session ends when one those two conditions holds:

• either the session ends when either commit or rollback is called:
  • if commit is called, the modified data is flushed back to its permanent storage,
  • if rollback is called, the modified data is "forgotten";
• or the connection is in auto-commit mode, in that case the session ends as soon as the write query ends (and in that case a commit is automatically performed).

Note that a session may be partially rollbacked using savepoints.

Select queries read data from the current session.

The queries

There are four kind of queries:

• Select: This query grabs data from a connection.
• Insert: This query inserts data in a connection.
• Update: This query modifies data in a connection.
• Delete: This query removes data from a connection.

The result set

A result set is a series of data returned by a Select query when run.

How is the data organized

The data is stored in a relational fashion: one or more tables, containing one or more rows and columns. Each table is described by its columns and contains rows. Each row has as many cells as the table has columns; each cell is typed (its type being the one of the column).

You can add constraints on tables (e.g. unicity constraints, primary keys...) and on columns (the column type, can the column be empty...)

At last, you can set indexes which speed up data retrieval.

More details about queries

Examples

Notes

1. ↑ Maybe there will be an SQL parser in the future, if someone writes one. It can be handy for people that extensively use SQL queries and find it less "strange" than Eiffel code.