Specifying design separately from construction
A major source of pain in the database development world is the fact that the construction steps for a database drive its design rather than the other way around. In the DataClass language, however, design is a first-class structure in its own right. It lives separately from the construction steps for any given version of a database class. A version's construction steps can then bind to elements of its design. In this way, a database class's logical design, rather than its construction steps, is the primary driver for any given instance's design.
Simple versioning and build management
The most basic task you can perform with DataClass is using it to capture, upgrade, and manage version upgrade scripts. DataClass does this by allowing you to document the construction steps required to upgrade to any given version from its immediate predecessor. The output of DataClass will manage choosing which scripts to execute and executing them in the right order.
Tamper-proofing database classes
The history of a database is of paramount importance. Each version of a database class serves as a foundation for its successor. It is critical that we not change the definition of a version that has been deployed to production and DataClass has features built in that defend against this.
Building a database
DataClass is a compiler that let's you organize and test the instructions for building a database into source files and then converts those source files into a .NET assembly or a java JAR file. Among other things, the resulting assembly (or JAR file) knows how to construct a database. It is the developer's responsibility to integrate those classes into their deployment mechanism of choice. You do not need to build both a JAR file and a DLL in order to build a database - you only need one. However, in this example, we will build both so that you can see how to use your platform of choice.
Organizing database versions
As your application matures, you will find that you are refining your databases many times. While it is important to keep a record of every single version that has been committed to production, it is a huge hassle to keep it all in one file. Database classes are inherently partial, which means you can define each version in its own file and DataClass will merge all of the versions of a database together as though you had written them all in one file.
Getting compiler feedback on your database design
Database build scripts have, for a long time been glorified strings that cannot be validated until executed on a database server. Of course, there is no way to totally validate any code until it has been loaded into a realistic environment and thoroughly tested. However, a lot of simple things can be caught at compile time if you have a compiler. DataClass does exactly that, giving you quick feedback when your database construction steps reference symbols that have not been specified.
Eliminating duplication between client and database code
There are a number of concerns around changing a database’s design. One of the bigger risks is that a database’s design might get out of sync with its clients. This is not an excuse to simply leave a database’s design in place without ever changing it; that pretty much guarantees it will be abused or become irrelevant. Instead, this is an opportunity find and eliminate the root cause of the problem: duplication of symbols and design descriptors between database servers and clients.
Deriving creation scripts from design
You don't always want DataClass to tell you what to do, obviously, so we give you the ability to put any SQL transition scripts in you like. Then we augment that with the ability to bind in symbols from your delineation of design. A lot of the time, however, you don't really want to do anything special - you just want a standard way of declaring a table or column. For that reason, we've added a few simple "shortcut" attributes to certain special design elements.
Keeping clients coupled to the current version
DataClass enables compiler feedback on the coupling between a client and a version. It also provides a mechanism to ensure that clients maintain strong coupling to whatever the current version of a class of databases is.
Leveraging a version's proxy in a client
For every version of a given database class, DataClass generates a proxy object based on the design of that version. At a minimum, a proxy wraps up a connection and ensures that clients operating through the proxy are connecting to instances of a database class that have been upgraded to the exact right version. The amount of interface an behavior available in this proxy. The proxy class has a tree of objects that allow easy binding of design element physical names into dynamically-generated SQL strings. It also has a method on it for each procedure design element. If done right, a database instance can look like "just another object."
Transition testing
For database development to be truly agile, deployment to production must have absolutely no manual intervention. This means that you have to have complete confidence that it will either work or have no effect at all. You can cover some ground by making your transitions defend against broken database changes. The rest is handled with transition testing, which you use to verify that a database moves from one version to another as expected.
Other Actions
documentation | all examples | use cases | concepts | keywords