SQL::Statement unusable in major Linux distributions

[H.Merijn Brand]

On Mon, 26 Oct 2009 09:05:01 +0000, Paul Beardsell <paul at Beardsell.com>
wrote:

> Please see sql-statement bug 50788 which
> shows several versions of  SQL::Statement to be
> unusable.  E.g. version 1.15.  It is this version
> of SQL::Statement which exists in many GNU/Linux
> distributions including Debian oldstable, stable and
> testing (and derivatives); Hardy, Intrepid, Jaunty
> and Karmic (i.e. all recent and current and the
> forthcoming releases of) Ubuntu (and derivatives);
> the more recent releases of Redhat (and derivatives)
> and Suse (and derivatives).

SQL::Statement 1.15 is dead. Dead as a doornail, and will not be
referred to for fixes. Forget *anything* below 1.22 unless you can
prove something still worked in 1.15 and does not in 1.22 and you
have both code and data to show us why.

If you tell the module maintainers that the distributions you mention
do not update to more recent versions of your favourite modules,
contact the distribution managers to update their modules. We, as
module authors, already fixed things, and we certainly do not control
the behaviour of those that make distribution updates available.

Sorry. You cannot blame us.

OpenSuSE indeed still ships perl-SQL-Statement-1.15-1.72, but it is not
up to us to *force* them to make the decision to replace that with what
we already fixed. We should not be your target of complaint!


I personally use SQL::Statement-1.22 + DBD::CSV-0.25 on
DBI-1.609 on a *DAILY* basis in *PRODUCTION* code for
converting CSV to Postgres. So statements as "unusable"
do not apply. BTW I am on OpenSUSE 11.0 and 11.1, but for
the reasons you mention, I never use system perl (neither
on other distributions of *nix like HP-UX or AIX)

$ perl -MV=DBI,DBD::CSV,SQL::Statement
DBI
        /pro/lib/perl5/site_perl/5.10.1/x86_64-linux/DBI.pm: 1.609
DBD::CSV
        /pro/lib/perl5/site_perl/5.10.1/DBD/CSV.pm: 0.25
SQL::Statement
        /pro/lib/perl5/site_perl/5.10.1/SQL/Statement.pm: 1.22

CSV as a database is not the way to create applications
that need speed or need low memory footprints or need
full ANSI-SQL support. If you need either of those, do
convert CSV to SQLite or postgresql (or another database
of your preference that does support all of your needs).

In the DBI/DBD world,
* CSV does not support types (beyond NULL, integer and char)
* CSV does not support links (referential integrity)
* CSV does not support speed
* CSV does not support data dictionary persistence

> The later versions of SQL::Statement are not available
> for ready installation into any of these Linux

There are a lot of references on the internet on how to install modules
in your *own* userspace that overrule modules in system space

$PERL5LIB is your friend

> environments by ordinarily competent Linux users.

"competent" implies people know how to set a single environment variable

> Even for the distro maintainers these latest releases
> are very disruptive (ripple on effects etc) to install
> owing to numerous dependencies on very new code.

so?

> Similarly older versions of SQL::Statement known not
> to suffer from bug 50788 are also not available for
> anything but very difficult if not nearly impossible
> installation into any recent release of these Linux
> distro.  E.g. 0.1020 does not suffer from this bug
> and 0.1020 was std in Debian Woody but Woody is no
> longer readily downloadable.

We do not refer to anything older than 1.22 thanks

> Consequently, to all intents and purposes
> SQL::Statement is *dead* in the Linux (distro)

far from ...

> world as it can not have any serious use in its
> currently (readily) available incarnations owing to
> the existence of at least one critical bug in S:S.
> 
> Why?  Why is there no usable version of SQL::Statement
> out there for (less-than-uber-techie) (common) Linux
> (distro) users?

Again, don't ask us, ask the linux distribution people.

> For a package to be used it must be reliable and
> available.

From our perspective it is.

> If(!) there are reliable versions they are not (easily)
> available.

Not our problem, as we think CPAN *is* easy.

$ cpan SQL::Statement

> What a pity!  SQL::Statement was a great package

it still is. Better even, as Jens took over, functionality grew.

> uniquely allowing SQL to be used on CSV files.

Better, I worked together with Jens to make SQL::Statement
support the new needs for DBD::CSV so *I* could use it for my daily
work. We will admit there are still a few black spots or minor nags and
inconveniences, but it does meet my needs now.

The toolchain for DBD::CSV is more complicated than for say DBD::Pg,
but I can say I am proud on what we have achieved. The fact that you
need newer versions of modules than what you have readily available
only proves that we work (very) hard to make it work as it should work.

> Was.  Now it is broken.

Was. Now it is fixed.

> The world needs, we need, *I* need SQL on CSV files.

Then install DBI-1.609 or newer, SQL::Statement 1.22 or newer and
DBD::CSV 0.25 or newer. We cannot help you if you decide to keep living
in the past.

> I very strongly suggest that one of three things
> be done.
> 
> (1) If there exists a stable and usable version of
> SQL::Statement after the known-to-be-broken 1.15 then
> this must be pushed at the Linux distro maintainers.

I urge you to take actions to make this happen!

> There must be reasons why *no* popular Linux distro
> has accepted any version after 1.15.

We'd like to know. They never contacted us.

> I know not what all
> these may be but I suggest but I suggest the
> very recent version 1.22 is very difficult to install
> into a working environment or into current Linux
> distros because of numerous dependencies on some very
> new code.  Because 1.22 is difficult to install it
> has practically zero users and I suggest therefore we
> do not actually know for sure it is a good version!
> A backport of a recent S:S version such as 1.22 to
> an earlier Perl environment is needed so that it can
> be installed without having to upgrade much of one's
> whole Perl environment.  Then we can get it into the
> distros, and get some users.

But again, not our problem.

> *or*
> 
> (2) Forward-port a known to be good version of
> SQL::Statement such as one of the pre 1.0 versions.
> I can vouch for 0.1020-2 as found in Debian Woody.

No.

> *or*
> 
> (3) Fix 1.15.

No.

> OK, so now shoot the messenger.  :-)

Is that an actual option?

Remember that CPAN is built and maintained by people on a voluntary
basis in our free time (FWIW I quite often would prefer to go skiing
than to maintain Text::CSV_XS). We are not being paid. Neither to code,
nor to fix bugs. If you think you are able to make all of this better,
you should do so by supplying patches. Patches to *recent* versions of
the module. All patches (except maybe for documentation) should be
accompanied by new test cases that provide proof.

> Paul Beardsell

-- 
H.Merijn Brand  http://tux.nl      Perl Monger  http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/           http://www.test-smoke.org/
http://qa.perl.org      http://www.goldmark.org/jeff/stupid-disclaimers/