[EMAIL PROTECTED] writes:
> Interesting developments.
>
> Michael is currently overseas, with limited access to email, so we may not
> hear from him on this subject.
>
> I had health issues that dragged on for an extended time, followed shortly
> thereafter by the birth of my twin sons,
hey congrats! kids rule!
> for which I took a leave of absence so that I could enjoy being a father
> before throwing myself back into work. I also took some time to do some
> writing about my experiences with Microsoft's .NET Platform for a couple of
> magazines and an upcoming book.
Bad to hear :)
> This does not mean that nothing was happening on the project. As was
> discussed quite some time ago, the current architecture is not suited for
> trying to build a more robust product on.
Possibly. People are using the current architecture and we need to move forward
with it. This includes better documentation, integration of bugfixes, etc.
I have no opinion on this codebase design vs a 2.0 redesign.
> The following tasks where discussed in regards to a 2.0 redesign:
>
> A redesigned parser, based on Antlr. I was not in favor of this particular
> tool choice at the time, however after having developed the new grammar with
> it I do prefer it over the Flex/Bison approach. I do feel that the enforced
> use of the antlr.jar by the generated parser is not the nicest thing, and a
> traditional approach might improve speed, but the difference is likely trivial
> and not worth the effort. The generated code is much easier to work with than
> that produced by one of the applications that translates Bison output into
> Java.
>
> The inclusion of a dynamically loadable query optimizer. It is quite possible
> to write really poor queries that cause extra work for the execution engine,
> especially if you move beyond simple transactional processing statements and
> start doing reporting. My research led me to David Dewitt with the University
> of Wisconsin, and the OPT++ optimizer framework. It was designed in C++, but
> the core concepts were portable to Java. It's inclusion does greatly increase
> the size of the jar file, there are 136 classes in the optimizer alone.
I don't know that the size of the jar file is relevant except for those
developing applets.
This is yet another reason for stabilizing the current code base while possibly
moving onto another architecture.
> An improved execution engine. In the current engine, there is a single path
> to execute any query. For instance, if you've studied relational theory, you
> know that there are numerous techniques for optimizing join operations.
>
> Locking. Implementing a non-blocking method of locking is critical to
> maintain performance. The approach I proposed was to incorporate a technique
> called transient versioning, where every row object has an integral version
> number. This works extremely well, especially on databases with a read
> dominated access pattern.
>
> Improved storage manager. The current storage management is rough at best.
> Any checkpoint operation requires rewriting the entire data file. A
> detailed discussion of the new design should be on the sourceforge site.
Yes. I agree. Of course this discussion is very technical and should not be
done on the site but in the mailing list.
> Logging and checkpointing improvements. Some early discussions of this should
> also be on the site.
>
> Statistics management. Adding this was necessary to perform any meaningful
> query optimization work.
>
> Why isn't all this in CVS? Because I am behind a firewall which has HTTP
> tunneling disabled, and cannot use CVS outside our network.
Come on... there is no excuse for working outside of CVS.
If you are outside of CVS, you are outside of the project. :(
If you can not use CVS on your network, get on another network.
Besides. CVS at sourceforge uses SSH not HTTP.
> Also, since this new architecture constituted a complete rewrite, until
> something was usable I saw little point in listening to the "I can't
> build/run/use the latest code from CVS". Publishing the 1.60 code that I did
> initially was done by emailing it to Mike, who got it put into CVS.
Constructive feedback is very important if you plan a rewrite. MORE important
than the code base we are working on because peer review is important in this
process.
> I'm glad that I was able to pull some people together so that HypersonicSQL
> did not simply die, and I've been pleased to see people have started
> contributing. For some time all I got was complaints like "My query that
> contains 14 join clauses isn't executed properly by HSQLdb, when are you going
> to fix it?"
We need a team which is willing to deal with these issues. I think it is
healthy to have some people interested in a 2.x generation but we need to have
people focused on quality of the 1.x generation as well.
> Unfortunately I find myself with little time or enthusiasm for the project
> given some recent developments, not the least of which is the need for more
> time with my family. I am not sure what would be required in order to remove
> me from the project on Sourceforge, since I am 'the owner' so to speak. I
> will contact them regarding this tomorrow, turning it over to Mike if
> possible.
>
> I look forward to seeing where you take the project from here.
<snip>
Someone needs be admin. Can this be multiple people?
Kevin
--
Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] )
Location - San Francisco, CA, Cell - 415.595.9965
Jabber - [EMAIL PROTECTED], Web - http://relativity.yi.org/
Given the price-conscious nature of this sector, Linux would be the odds-on
favorite, since it typically costs no more than a fifth the price of Windows
2000.
_______________________________________________
hsqldb-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
