From: Jan-Benedict G. <jb...@lu...> - 2007-03-22 16:06:30
|
On Thu, 2007-03-22 11:49:11 -0400, Paul Smith <ps...@ne...> wrote: > On Thu, 2007-03-22 at 16:24 +0100, Jan-Benedict Glaw wrote: > > That said, I think we should have a view at the documentation again. > > After that, lets release v1.0 and focus on the new goodies afterwards. >=20 > That sounds fine, but maybe a 0.9.5 release for people to test before > 1.0? Sure. > > There's also the exit() compatibility patch for perl5. I think this > > should also go in before v1.0 is pushed out. >=20 > Critical to get in, IMO, are the enhancements to allow the code to work > with MySQL 5 (the quoting of `release` so it's not considered a > keyword). A number of the bugs and patches on the Savannah site all > deal with this single issue. That may need a fix. If the DB backend gets rewritten to make deeper use of the DBI interface (eg. don't do too much database specific stuff), that'd hopefully be dropped altogether. Renaming the field to avoid the issue could help, too. And a Perl guru could have a look at the documentation to tell us if DBI has a generic interface for prepared statements. > There needs to be some cleanup in this as well; note that the lxr.conf > file allows you to rename the database and table prefix, which is > great... but there's no way to CREATE those databases/tables with > different names other than editing the initdb-* file by hand, which is > not so great. Right. > Maybe the initdb-* files need to become Perl scripts, which can read > lxr.conf and make the appropriate substitutions. Then the invocation > model could change to something like: >=20 > ./initdb-mysql | mysql > ./initdb-postgres | psql >=20 > (not sure for Oracle). I can look into that if people think it's a good > idea. The interesting part here is most probably to correctly deal with dropping the old tables... MfG, JBG --=20 Jan-Benedict Glaw jb...@lu... +49-172-7608481 Signature of: http://catb.org/~esr/faqs/smart-questions.html the second : |