Axion: Developer's Guide: Design and Development Philosophy

Complete

Axion aims to be a complete relational database engine. This implies:

• Complete support of the relevant SQL standards.

• Complete support of JDBC and other relevant Java specifications.

• Support for commonly found SQL and relational database extensions.

• Adherence to E.F. Codd's 12 Rules for a Fully Relational DBMS.

• Support for the ACID database properties: Atomicity, Consistency, Isolation, and Durability.

We have not yet achieved all of these goals, but we're well on our way. See the Recommended Readings list for more information on these standards, specifications and concepts.

Robust

...tk...

...durability...

...freedom from defects...

...limited functionality over false feature richness...

...if Axion does it it does it well...

Modular

...tk...

Scalable

...scale up and down...

...fast...

...small footprint...

...tunable/configurable for a different applications...

Extensible

...tk...

...a database engine, but also toolkit for building database engines...

Open Source

Axion is made available under an open source license, but more importantly, is developed under an open source philosophy. Axion's particular flavor of open source means:

• Axion the product of a collaborative development process.

• Axion is available under a commercial-friendly license.

• Decisions are made via a transparent, public process.

• Communication is open, honest, and respectful.

• The process is open to committers, contributors and to users.

Agile

Axion's day to day development follows a largely agile development process. This includes such principles as:

Automated Testing

Axion includes a robust, fully automated test suite that covers the vast majority of the code base (and covers more and more of it every day). A frequently executed, fully automated test suite gives users assurance that Axion's features work as advertised, and gives developers the confidence to add features and continually improve the implementation without fear of introducing new problems.

Test Driven Development

Axion follows a "test first" or "test driven" development process.

Before adding a feature or addressing a bug, an Axion developer will first write an automated test that specifies the feature's interface and behavior. Only once a test that fails has been created will the developer change the production code (in an effort to make the test pass). Development proceeds as a series of small iterative cycles of writing tests then writing "production" code.

This test first protocol supports an incremental and evolutionary design process, leading to an well-tested, implementation closely fit to the currently supported features.

Note that this process is as more about design as it is about testability.

Simplicity

The Extreme Programming philosophy advocates implementing "the simplest thing that could possibly work". That is, at every step ensure that the system is the simplest implementation of the set of tested requirements. Little or no time is spent building in generalizations or extension points that aren't currently used. (Such generalizations are created, when needed, by refactoring process.)

By building a system that simply and minimally implements the current set of supported features, Axion is able to remain nimble enough to quickly and easily implement additional feature when they become necessary. Axion's history has shown this to be an effective process.

Refactoring

In support of a nimble implementation, the Axion team continually looks for ways to improve the design and implementation of the engine. Typically these improvements are executed by a series of "refactorings".

Working with a constant test suite, an Axion developer makes systematic changes to the "production" code base, in ways designed (often demonstrably proven) to improve or simplify the design of the system while not changing the external functionality of the system. Tools like Eclipse and IDEA are often used to support this process.

Since Axion's external interface (JDBC) is well defined, we are able to mercilessly refactor the engine implementation while maintaining a consistent and compatible interface for our users.

This section fails to do these concepts justice. See the Recommended Readings list for more information on agile development philosophies.

Design

...arch not lintel...

Client Oriented

...community driven features...

...release early, release often...

...backward compatibility...