[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[nrdo-list] nrdo weekly news: 2003/05/05
[nrdo-list] nrdo weekly news: 2003/05/05
Mon, 05 May 2003 09:36:39 -0400
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030327 Debian/1.3-4
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
- Make some kind of build procedure that ends up with nrdo.jar and
- 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
- 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
- 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
|[Prev in Thread]
||[Next in Thread]|
- [nrdo-list] nrdo weekly news: 2003/05/05,
Stuart Ballard <=