Another message I sent privately by mistake... On 12/13/01 5:07 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> > Interesting developments. > > Michael is currently overseas, with limited access to email, so we may not > hear from him on this subject. I think as a developer he will always have a say, so whether it's sooner or later it will count. > I had health issues that dragged on for an extended time, followed shortly > thereafter by the birth of my twin sons, Congratulations! > 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. > > 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. Maybe so, but finding reference to anything has proven difficult. Many people have mentioned this. Not anyone's fault, just unfortunate. > 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. I'm a JavaCC guy myself :-) But pluggable parsers is always an option, one for speed possibly on embedded platforms, another that is complete. Many options there. > 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. There are few optimizers around based on some decent graph code, that's something I'm definitely interested in. > 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. All very cool, but definitely definitely not in plain site. This is the first time I've heard of anything like this and I know I am not the only one. > 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. > > 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. 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. Fair enough, but this made it very difficult for anyone to know what was actually going on. If you have references to the discussion (maybe in the forum) or if you have some documents I think Kevin would love to add them to docs he's working on. > 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?" That's part of the game! > 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. How about turning it over to the developers who want to do something with the project? That appears to be the general consensus from anyone that has responded. > I look forward to seeing where you take the project from here. Thanks for the support! > Mark > > _______________________________________________ > hsqldb-developers mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/hsqldb-developers -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons ------ End of Forwarded Message _______________________________________________ hsqldb-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
