Thoughts about Rapid Development Tools

by Kevin Scaldeferri

The major complaint about the new object system is that data modelling is significantly more tedious than it used to be. Partially that is unavoidable as we move more functions into PL/SQL, but much of declaring object types and attributes and writing constructor and destructor methods is unnecessarily tedious and repetitive. Emacs cut-and-paste helps a bit, but I've caught a lot of errors in code reviews that were caused by cut-and-pasting without carefully making all the changes needed for each case. While I don't think we can expect to completely avoid people having to write some of their data model by hand, I think it is reasonable to develop some tools to simplify the process and avoid some of these careless errors. An added bonus of this is that we can enforce standards in naming and formatting by automatically generating much of the SQL.

Vision

I'm envisioning a web interface to create the SQL for a new object type. Users specify the supertype and the columns in the new table. They can specify which should be acs_attributes and primary key, foreign key, unique and not null constraints. Arbitrary check constraints are tough, although we should build in the "boolean" type. We generate the calls to make the object type and register the attributes and we generate the basic new and delete functions for the PL/SQL package. Other methods will have to be written by hand (although we could certainly generate selector methods as well.)

Implementation

There are a couple ways that we could be storing the information as we work on it. We could keep everything in HTML form variables (could end up being a lot of variables). We could actually build the SQL file as we go (lots of parsing and text manipulation). We could actually store metadata about the data model in the database (seems like overkill, but might be the best way to go). We could create our own data structure, either a TCL array structure or an XML document, to store the information (again, a lot of parsing, but probably not as painful). Is there any sort of XML standard for database schema?

I think initially metadata in the database and a proc to turn it into SQL is the way to go, but XML sounds appealing for the future.

Hazards

There are places where this approach could screw up. For example, subtypes of the content_item object type should be created using the content_type.create_type method rather than acs_object_type.create_type. Also, in many cases, people will want to do some additional things in the new or delete methods.


kevin@arsdigita.com