[nrdo-list] nrdo weekly news: 2003/05/05

[Stuart Ballard]

This is an attempt to expose some of what's going on with nrdo to the 
outside world. Even if nobody reads it now, it will show up in the 
mailing list archives and therefore provide some background to anyone in 
the future who's looking into nrdo.

Since this is a first issue, it will be covering more than a single 
week. Hopefully I'll remember to keep this going on a weekly basis from 
now on, at least when there's any ongoing development to report on.

A spurt of development over the last few weeks has been triggered by 
Michael Hitchcock (address@hidden) who wanted to get 
nrdo to work with Microsoft Access, of all things. Up until this point 
nrdo's "database independence" was essentially a few if()s in 
TableCreator that checked whether the dbadapter was mssqlserver, and 
assumed oracle if not. Mike cleaned up the if()s considerably, adding 
explicit checks for each possible dbadapter, and adding code for Access. 
This got the creation of tables working, but that was the easy bit.

All our C# code generation used to hardcode the use of SqlClient. My 
theory is that Microsoft specifically designed the .NET framework to 
encourage database-vendor lockin: almost every line of code that touches 
the database will, unless you make a point of avoiding it, include a 
reference to SqlThis or OleDbThat.

After adding a bunch of conditional cgl to say Sql or OleDb depending on 
the dbadapter, it turned out that it's even worse than that: the 
different database providers in .NET have wildly different behavior when 
it comes to how you specify parameters. SqlClient uses named parameters 
referenced as "@name", OleDb uses positional parameters referenced as 
"?". Bizarrely, Mike found that using "@name" named parameters worked 
perfectly except for inserting values into primary key fields, but since 
we needed to be able to do that, it became clear that we needed to 
support positional parameters in C#. Fortunately, the code for 
generating Java code already does this, so it was just a matter of 
knowing which code to steal...

Michael also solved a bunch of other minor issues and eventually 
reported success using nrdo with Access to run a large application.

Meanwhile, Michael's work cleaning up the DB-independence inspired me to 
improve the abstraction of that code so we didn't have if()s all over 
the place. I implemented a DBAdapter class defining methods for 
everything that might be database-specific, providing default 
implementations of each of them using whatever syntax was most common 
between all the supported databases. Then I implemented subclasses for 
each individual database that we support. I also implemented a similar 
but simpler trick in our C# runtime libraries, so that the same library 
can be used for multiple databases without even a recompile.

I also decided to take the opportunity while cleaning up the database 
code to add support for Postgres. You may recall that Postgres or MySQL 
support is a necessary condition to host nrdo's source code on Savannah. 
Due to all the hard work Mike had done identifying places where there 
were database dependencies, this has been pretty easy, so far. The table 
creation phase is working fine, and the C# code generation shouldn't be 
hard since Mono provides a nice .NET Postgres driver.

Finally in this issue, I've written a "TO DO" list for what I feel needs 
to be done before I'm willing to make a release of nrdo that I'm willing 
to consider trying to publicise. It's not exactly short, but at least 
the individual items in it aren't too big. For completeness, I'm 
including it here:

- Make everything that should be optional in the .nrdo file optional.
- Read all the documentation and make sure it's up to date.
- Document the C# bindings.
- Include "NRDO library" in the packaging, including the mknrdotypes script.
- Support 'before' on queries.
- Eliminate the jdbcpool dependency from the toolchain - in fact 
eliminate the use of net.netreach.nrdo.DB, so that that class is 
runtime-only.
- Make some kind of build procedure that ends up with nrdo.jar and 
nrdo-rt.jar.
- Figure out a good installation structure for nrdo and see if we can 
get "make install" to do it on *nix. In fact see if we can make any kind 
of standard-ish build system at all, even if it's "make".
- Produce both .zip and .tar.gz downloadable tarballs.
- Make nrdo get its version from somewhere other than hardcoded, or at 
least from a file whose sole purpose is to define the version.
- See if we can package the nrdo toolchain as an exe and a dll using 
IKVM. JDBC drivers will be the biggest problem, especially those that I 
can't distribute. Perhaps ship with a /R to each of them but not the DLL 
itself, and provide instructions on how to construct the DLL from the 
jar files.
- Make sure the toolchain can run under Kaffe or gcj or ORP or Kissme.
- Debug classpath/kaffe's AbstractMap impls to make sure they're really 
identical to Sun's, since this appears to cause Scope some problems.
- Get PostgreSQL support working fully, including the PgProvider in C#.
- Make sure the runtime can run either under a free VM (for java) or 
under Mono (for C#). Ideally both! Actually the runtime is probably 
easier than the toolchain, because it doesn't do anything terribly complex.
- Given Postgres support and free VM support, get nrdo's source hosted 
on Savannah.
- Document the process of building a project that uses nrdo, both by 
hand and in Visual Studio.

That's about all I can remember happening recently. See you next week!

--
Stuart Ballard, Senior Web Developer
FASTNET - Web Solutions
(215) 283-2300, ext. 126
www.fast.net