Re: DBD::mysql path forward
On 11/09/2017 09:54 AM, p...@cpan.org wrote: As those people or projects misuse some internals of perl we cannot guarantee anything such that which may be broken or changed by updating any module from cpan or external source not related to DBD::mysql. Pali. This "argument" applies to a large portion of CPAN. All JSON variants, various web frameworks, even things as mundane as math libraries: https://rt.cpan.org/Public/Bug/Display.html?id=123268 As already stated more times, if there is some code which depends on some internals, it should stay conserved in tested version as it can break by updating anything (also unrelated). There is no other option how to achieve that code stay working and does not corrupt something else. Pali, this is *not* how CPAN works. Nor is this even how /usr/bin/perl works. Maintaining such thing is something what I believe nobody wants. For sure I'm not. I will state several very obvious ( to me ) things, apologies if they seem condescending: I simply do not know whether the participants on this thread are talking about the same thing. Pali's entire premise is flawed. In the grand scheme of things it makes absolutely no difference what "maintainers want". Zero. What the complaints in this thread are focused on is what the *users* want. And every maintainer, Pali included, are irrevocably bound by the general direction of wishes of the userbase. The wishes are roughly ( and in order of inmportance ): - Breakage is never silent and is rectified swiftly when reported ( and is ideally never argued about ) - Upgrades are noneventful as a whole, and are as modular as possible ( i.e. a DBD upgrade does not drag in Test2 or something similarly non-relevant ) - The overall library seems to move in a "better direction" ( more performance, less memory use, support for newer protocols, etc ) Satisfy the above - and you do get the privilege of being a maintainer of a central module with 15+ years of history. If one can't - then the user-base is better off with the module remaining "unmaintained" ( reusing Pali's terminology ), and Pali's brave-new-world plan ending up in a different namespace. DBD::MariaDB is an idea. Cheers
Re: DBD::mysql path forward
On 11/09/2017 01:46 PM, Noel Butler wrote: On 09/11/2017 21:32, p...@cpan.org wrote: What the complaints in this thread are focused on is what the *users* want. and the users want now, or will need in the near future, to build with latest, stable and recommended versions of MariaDB and MySQL. Which is a great thing to want. I want this too. This is not what the thread is about. The problem stems from Pali mashing together 3(!)* independent concerns, and presenting them as an "all or nothing" proposition: 1. Inability to build against latest libmysql libs 2. Several security fixes 3. Entirely redefining how unicode is handled throughout the stack If the ( artificial ) choice is the-above-3-together-or-nothing, then the logical answer is "of course we rather have nothing until someone else comes by and fixes 1 and 2, leaving 3 alone" If Pali is willing to *permanently* back off from changing anything related to 3 ( regardless how displeasing it is ) - then this becomes a completely different conversation. Not even a hint of such willingness has been demonstrated. This is what is being discussed. Cheers * There are actual 4 issues: there is also intentional breakage of bigint handling within the driver, which already shipped to CPAN at the start of 2017 and still has not been backed out, despite multiple pleas, including at least one large Perl shop declaring that DBD::mysql is unusable to them as it stands right now: https://github.com/perl5-dbi/DBD-mysql/pull/74
Re: DBD::mysql path forward
On 09/12/2017 07:12 PM, p...@cpan.org wrote: On Tuesday 12 September 2017 12:27:25 p...@cpan.org wrote: To prove fact that other DBI drivers (e.g. Pg or SQLite) had fixed similar/same UTF-8 issue as MySQL has and behave Perl-correctly, I would provide test cases so you would see difference between Pg, SQLite and mysql DBI drivers. And here is promised script: The script side-steps showcasing the treatment of BLOB/BYTEA columns, which was one of the main ( albeit not the only ) reason the userbase lost data. Please extend the script with a BLOB/BYTEA test.
Re: DBD::mysql path forward
On 09/13/2017 09:58 PM, Dan Book wrote: On Wed, Sep 13, 2017 at 3:53 AM, Peter Rabbitson <rab...@rabbit.us <mailto:rab...@rabbit.us>> wrote: On 09/12/2017 07:12 PM, p...@cpan.org <mailto:p...@cpan.org> wrote: On Tuesday 12 September 2017 12:27:25 p...@cpan.org <mailto:p...@cpan.org> wrote: To prove fact that other DBI drivers (e.g. Pg or SQLite) had fixed similar/same UTF-8 issue as MySQL has and behave Perl-correctly, I would provide test cases so you would see difference between Pg, SQLite and mysql DBI drivers. And here is promised script: The script side-steps showcasing the treatment of BLOB/BYTEA columns, which was one of the main ( albeit not the only ) reason the userbase lost data. Please extend the script with a BLOB/BYTEA test. I'm not sure how to usefully make such a script, since correct insertion of BLOB data (binding with the SQL_BLOB type or similar) would work correctly both before and after the fix. If you were to actually try to make the requested addition you'd have noticed that DBD::Pg *DOES NOT* require one to binding with SQL_BLOB. For more info please go back to the old ( 2013 ) RT threads on the "mysql unicode issue" and read again carefully. Please try to actually implement this - it will give you additional perspective.
Re: [Dbix-class] Escaping placeholders
On 12/20/2014 03:38 PM, Tim Bunce wrote: On Fri, Dec 19, 2014 at 01:12:16PM +0100, Alexander Foken wrote: Hello all, this reminds me of a similar problem I had in 2000 with DBI, DBD::Oracle, and Oracle. See http://marc.info/?t=9506395904r=1w=2, http://173.79.223.25/?l=dbi-devm=95077716125217w=2. Problem was using named placeholders (:foo) in DBI and at the same time use PL/SQL code containing variables (:bar), DBI considered both :foo and :bar to be placeholders instead of leaving :bar alone and pass it to Oracle. A set of patches from Michael A. Chase allowed disabling parts or all of the placeholder parsing, so using unnamed placeholders (?) allowed using PL/SQL variables in SQL statements. But the fundamental problem was not solved, there was and still is no way to escape placeholders. Can you, or anyone else, think of any situation where a backslash before a ? or :foo (or even $1) style placeholder might be valid SQL? So far no one has come up with one, so I'm getting more comfortable with the idea that a backslash before a placeholder is a safe change. I.e., there's a near-zero risk that upgrading a DBI driver to support backslashes would cause breakage in existing code. I am not sure why but a backlashed version makes me wary... What about ?? instead?
Re: How can I...
On Mon, Jun 06, 2005 at 01:11:30PM -0700, Vergara, Michael (TEM) wrote: Hi Everyone: I want to connect to an Oracle database and test for the existence of a table. My first thought was to SELECT COUNT(*) FROM TABLE, but DBI catches the ORA-942 error and I don't know how to catch that. It throws the error during the $dbh-execute step; how do I catch an Oracle error returned from that step? Or...is there a better way? Thanks, Mike Yes there is, and it is even portable (or so they say) across different vendors. Look for the table_info () method at http://search.cpan.org/~timb/DBI-1.48/DBI.pm#Database_Handle_Methods Peter
DBI + XML::Twig conflict (?)
I have a strange problem where a database handle is being destroyed for no
apparent reason. My initial idea was to parse some xml, and translate it
into a database. Deleting line after line of code I came up with this short
meaningles program which exhibits the same behavior as its real-life
sibling (tested against two different mysql instalations on different
machines):
use warnings;
use strict;
use DBI;
use XML::Twig;
++$|; #so I can see the progress in _dummy ()
my $dbh = DBI-connect ( dbi:mysql:$random_db:localhost,
$user,
$pass,
{AutoCommit = 0,
RaiseError = 1,
PrintError = 0,
}
);
unless ($dbh) {
print Unable to connect:\n$DBI::errstr\n;
exit 1;
};
eval { $dbh-do (DROP TABLE IF EXISTS some_nonexistant_table) };
die ($@) if $@;
my $objinfo_parser = XML::Twig-new (
twig_handlers = {
'Products/Product' = \_dummy
}
);
$objinfo_parser-parseurl ('http://www.3btech.net/3btech/objinfo.xml');
$dbh-commit;
$dbh-disconnect;
exit 0;
sub _dummy {
my ($twig, $child) = @_;
print '.';
$twig-purge();
return 'dummy';
}
Note that I am not even doing any real operations on the MySQL side, thus I
don't care what database I connect to. I put the DROP TABLE there just to
make sure that commands are reaching the server, and yes I can see that in
the logs.
If I run the real program I end up stuffing about 480 out of roughly 510
products into a designated table and then the handle goes out to lunch with
the same error message.
I use the very same XML::Twig setup in another script that packs results
into a hash and returns it, and everything works flawlessly. Any help is
priceless, as after nearly two days playing with this I am totally lost...
Thanks
Peter
