Skip links

Format Validation in CodaServer

Author: Published on: Published in: Blog

This is a repost of an article from my old blog about CodaServer. It’s being published here for posterity.

Validation means many things to many people.  It’s that feeling you get when you are unconditionally accepted by the one you love, when all the toil and tears finally…

Uh…

For most of us programmers, validation comes in two forms:

  • Format-level Validation: Does this piece of data look the way it should?
  • Data-level Validation:  Does this properly-formatted piece of data represent an appropriate value for where I’m seeing it?

This article will focus on the former.

The Old Way

Using conventional technologies, format validation has been something of an annoyance for us.  Every layer of the application stack makes a token effort at addressing it, but none of them actually complete the job, and we are left negotiating between them.

  •     The database has database types, such as VARCHAR, NUMERIC, and BLOB.  As the final resting place for data, these place the most basic constraints on what it can look like and how much space it can occupy.  Of course, each database has slightly different constraints here.  A CLOB in Oracle is a TEXT in MySQL, VARCHARS can be 4000 characters in Oracle (I think, it’s been a while) but only 255 in MySQL.
  • Application languages have their own types, like ints and Strings, which kind of map to SQL types.  Except when they don’t, when they are arrays, or classes.  Adaption code must be written to handle this conversion and ensure the application values fit into the database.
  • Application frameworks often include their own validation layers for processing form input and making sure it conforms to some higher level structure.  Is that string an email address?  Does that purchase order number look like one of ours?  How about the ZIP code?  What about a Canadian postal code?  Usually the frameworks include limited number of these validators and leave it to the developers to round out the set.
  • Sometimes Javascript is employed to stop bad data from ever leaving the web browser.  Just in case.

And this is only one application language on one database.  Perl libraries for validation can’t be used in Ruby.  Let’s rewrite ’em!  All this format validation hassle adds virtually no value to the final application, but it needs to be done anyway.

The CodaServer Way

Naturally, CodaServer has an answer for this problem:

An Extensible Type System!

Natively, CodaServer has 8 datatypes as well as an Array specifier. These correspond closely to the SQL types and are pretty generic containers for data. The real power comes from the ability to define your own types using the CREATE TYPE command.

CodaServer utilizes regular expressions to give you virtually unlimited ability to describe what your data should look like.  (If you are unfamiliar with regular expressions, there are many great resources to get you started online.  I use this site a lot to get ideas, and this site to test them out.  CodaServer uses the Perl type of regular expression.)

The CREATE TYPE command has the following syntax:

CREATE TYPE email_address AS (
validation_mask = '/^(.+)@([^();:,<>]+.[a-zA-Z]{2,4})/',
save_mask = '/^(.+)@([^();:,<>]+.[a-zA-Z]{2,4})/'
);

The validation_mask value determines whether or not CodaServer throws an error, and the save_mask determines how the validated result is saved to the database.  This uses a facility called regular expression substitution which is a beyond the scope of this article, although there are resources online that can give more details.

That’s all there is to it!  Now you have a new type that is available server-wide.  You can use it in procedure argument lists, table definitions, procedural code blocks… where ever you would like.

On the application code side, you can simply pass in whatever the user submits in a form and CodaServer will tell you whether or not it validates.  And (there’s more!) CodaServer’s ability to return multiple error messages with each statement means that you can submit your whole form, and you will get back all of the errors at once.  No more of the “submit and see what else is wrong” that other database systems make you do.

Doesn’t that feel better?

Til next time.

You may also like