DBD::MariaDB 1.23

Hello, New version of DBD::MariaDB 1.23 is now on CPAN: https://metacpan.org/release/PALI/DBD-MariaDB-1.23 DBD::MariaDB is DBI driver for connecting to MariaDB and MySQL databases. It is a fork of DBD::mysql driver which aims to work correctly with Unicode and to have a better support

Re: [USN-4503-1] Perl DBI module vulnerability

Hello Jonathan! On Wednesday 16 September 2020 11:25:52 Jonathan Leffler wrote: > I've not seen much (any?) traffic on this list recently. Is this list > still alive? > > This message arrived from Canonical/Ubuntu about a fixed bug in DBI — > numerous versions thereof (1.640, 1.634, 1.630,

Re: Testing DBI

On Tuesday 10 March 2020 14:50:18 H.Merijn Brand wrote: > On Tue, 10 Mar 2020 11:19:03 +0100, p...@cpan.org wrote: > > > On Tuesday 10 March 2020 11:15:54 H.Merijn Brand wrote: > > > • I upped Devel::PPPort to 1.58 > > > > > > Now I wanted to test DBI using Module::Release on all 131 versions I

Re: Testing DBI

On Tuesday 10 March 2020 11:15:54 H.Merijn Brand wrote: > • I upped Devel::PPPort to 1.58 > > Now I wanted to test DBI using Module::Release on all 131 versions I > have available that ought to be supported for DBI on a random Linux > machine and it fails on threaded 5.8.2 > > It passes on 5.8.1

Re: Better diagnostic support in DBI

On Monday 08 April 2019 20:49:25 Tim Bunce wrote: > > Tim, what is opinion for adding that new diagnostic API into DBI? > > I'd much prefer to wait till multiple drivers have added their own > driver-specific, and driver-optimized, interface. And then have a > discussion about how the DBI might

Re: RaiseWarn attribute for DBI

On Monday 15 April 2019 16:21:30 Tim Bunce wrote: > On Fri, Apr 12, 2019 at 10:22:57AM +0200, p...@cpan.org wrote: > > On Monday 21 January 2019 16:55:07 p...@cpan.org wrote: > > > On Sunday 20 January 2019 17:27:22 Tim Bunce wrote: > > > > > > > > Couldn't HandleSetErr be used for this? > > > >

Re: RaiseWarn attribute for DBI

Exactly, it is optional feature (turned off by default) which currently is really missing and seems that it even cannot be "simulated" by HandleSetErr. On Thursday 17 January 2019 18:24:26 Dan Book wrote: > While I'm a staunch opponent of fatal warnings in general, and I believe >

Re: RaiseWarn attribute for DBI

On Monday 21 January 2019 16:55:07 p...@cpan.org wrote: > On Sunday 20 January 2019 17:27:22 Tim Bunce wrote: > > On Fri, Jan 18, 2019 at 10:47:41AM +0100, p...@cpan.org wrote: > > > On Friday 18 January 2019 09:13:48 Tim Bunce wrote: > > > > On Thu, Jan 17, 2019 at 10:02:39AM +0100, p...@cpan.org

Re: Better diagnostic support in DBI

Hello, I would like to hear some feedback on this DBI API proposal. Tim, what is opinion for adding that new diagnostic API into DBI? On Tuesday 29 January 2019 13:16:23 p...@cpan.org wrote: > CCing DBD::Pg, DBD::Oracle and DBD::ODBC developers. What do you think > about following diagnostic API

DBD::MariaDB 1.21

Hello! New version of DBD::MariaDB 1.21 is now on CPAN: https://metacpan.org/release/PALI/DBD-MariaDB-1.21 DBD::MariaDB is DBI driver for connecting to MariaDB and MySQL databases. It is a fork of DBD::mysql driver which aims to work correctly with Unicode and to have a better support

Re: Better diagnostic support in DBI

On Thursday 24 January 2019 13:57:23 Daniël van Eeden wrote: > I think this would be very useful. > > Another thing you could consider is a hash where the error/warning number is > the key and an list of msgs is the value. I think this is just complicated to create create and use. Is there any

Re: Better diagnostic support in DBI

On Wednesday 23 January 2019 20:19:27 Tim Bunce wrote: > A key goal of the DBI is to provide a database independant interface to > databases to enable application portability. What you're suggesting > seems inherently database specific. As wrote DBI already has API for providing last

Better diagnostic support in DBI

Hi! DBI currently supports 3 functions to retrieve diagnostic informations https://metacpan.org/pod/DBI#err https://metacpan.org/pod/DBI#errstr https://metacpan.org/pod/DBI#state which return the last one database native code, message and SQLSTATE. Plus there warning or note information is

Re: RaiseWarn attribute for DBI

On Sunday 20 January 2019 17:27:22 Tim Bunce wrote: > On Fri, Jan 18, 2019 at 10:47:41AM +0100, p...@cpan.org wrote: > > On Friday 18 January 2019 09:13:48 Tim Bunce wrote: > > > On Thu, Jan 17, 2019 at 10:02:39AM +0100, p...@cpan.org wrote: > > > > > > > > Currently DBI has only

Re: RaiseWarn attribute for DBI

In my proposed implementation is HandleError called also for warnings when RaiseWarn is enabled -- so for everything which is (later) going to be passed to DBI's die. And based on return value of HandleError callback, die/exception can be either silenced or re-throw like for DBI errors.

Re: RaiseWarn attribute for DBI

On Friday 18 January 2019 09:13:48 Tim Bunce wrote: > On Thu, Jan 17, 2019 at 10:02:39AM +0100, p...@cpan.org wrote: > > > > Currently DBI has only $dbh->{PrintWarn} attribute to control warnings. > > When is set to true (by default) all warnings from DBI driver are passed > > to perl's "warn"

Re: RaiseWarn attribute for DBI

Personally I do not like changing Print/Raise. It is documented, implementation seems to match documentation, it is without bugs and current behavior is usable. Anyway, back to my question about RaiseWarn. Do you think that it make sense to have it in DBI? On Thursday 17 January 2019 11:02:51

Re: RaiseWarn attribute for DBI

On Thursday 17 January 2019 11:06:22 Alexander Hartmaier wrote: > I'm aware of that, semantic versioning and major versions exist to handle API > breakage. Such thing is unsupported by CPAN clients. So we cannot use it. Anyway, this is question for Tim as DBI maintainer. But I guess he does not

Re: RaiseWarn attribute for DBI

On Thursday 17 January 2019 10:23:25 Alexander Hartmaier wrote: > I don't see the benefit, Print* should die This would break existing API of DBI. Print just prints and Raise dies. This cannot be changed as there are many applications which depends on this API. > and I'd personally would release

RaiseWarn attribute for DBI

Hello! What do you think about adding a new attribute $dbh->{RaiseWarn} which cause that warnings reported by DBI drivers would behave like errors? For errors DBI has there $dbh->{PrintError} and $dbh->{RaiseError} attributes. First one is by default true and second one by default false. When

DBD::MariaDB 1.10 released on CPAN

Hello! I would like to announce that DBD::MariaDB 1.10 was released on CPAN. https://metacpan.org/release/PALI/DBD-MariaDB-1.10 DBD::MariaDB is DBI driver for connecting to MariaDB and MySQL databases. It is a fork of DBD::mysql driver which aims to work correctly with Unicode and to have

Re: Getting make error while installation

On Friday 03 August 2018 21:53:15 sushrut pajai wrote: > Hi Dev, > > I am trying to install DBD::MySQL driver on windows 10 64-bit machine. But > unable install due to following error. > > dmake > "C:\Perl64\bin\perl.exe" -MExtUtils::Command::MM -e cp_nonempty -- mysql.bs >

DBD::MariaDB 1.00 released on CPAN

Hello! I would like to announce public release of the DBD::MariaDB 1.00. Now it is available on CPAN and can be installed directly via cpan client. https://metacpan.org/release/PALI/DBD-MariaDB-1.00 There is a problem with perl mailing lists and perl email servers, therefore it is possible

DBD::MariaDB beta 0.90_01 released on CPAN

Hello, I would like to announce that after few months of DBD::MariaDB development, beta version 0.90_01 of DBD::MariaDB is now on CPAN: https://metacpan.org/release/PALI/DBD-MariaDB-0.90_01 DBD::MariaDB is a DBI driver for connecting to the MariaDB or the MySQL database. It is a fork

Re: Extend API for last_insert_id

> That seems fine. I'd write the fallback code like this: > > sub last_insert_id { return shift->{Database}->last_insert_id(@_) } Changed. And now I created a pull request with these changes: https://github.com/perl5-dbi/dbi/pull/64 > Thanks Pali. > > Tim.

Re: Extend API for last_insert_id

Hello, do you have any opinion or comments? Tim, you as a DBI maintainer, what do you think about those ideas? On Friday 27 April 2018 16:03:59 p...@cpan.org wrote: > Hello, > > I would like to propose two new changes to DBI which extends > last_insert_id API. > > First one: Allow to call

Extend API for last_insert_id

Hello, I would like to propose two new changes to DBI which extends last_insert_id API. First one: Allow to call $dbh->last_insert_id() method without arguments. Currently this method needs to take four arguments (plus $dbh) and XS code validates their count:

Re: DBD::mysql 4.044 released!

On Wednesday 31 January 2018 10:46:58 Patrick M. Galbraith wrote: > "Should I create a ticket?" > > Yes please. > > Thank you, > > Patrick > > On 1/25/18 3:44 AM, H.Merijn Brand wrote: > >On Tue, 23 Jan 2018 08:59:54 -0500, "Patrick M. Galbraith" > > wrote: > > > >>Dear Perl and

Re: New DBI driver DBD::MariaDB

On Tuesday 23 January 2018 11:14:13 p...@cpan.org wrote: > * Better compatibility with the MariaDB client library Basic unit tests passed on Travis with last MySQL versions 5.5.58, 5.6.38, 5.7.20, 8.0.3 and MariaDB versions 5.5.58, 10.0.33, 10.1.30, 10.2.12, 10.3.3. Also with MariaDB C/Connector

New DBI driver DBD::MariaDB

Hello, I would like to announce a new DBI driver for MariaDB and MySQL databases. As stated in the email [1] which I sent to this mailing list about a half year ago, we in the GoodData company decided to create a fork of the old DBD::mysql driver under the name DBD::MariaDB. The source code of

Re: DBD::mysql next steps

On Friday 10 November 2017 10:13:55 Patrick M. Galbraith wrote: > Greetings all! > > Michiel and I have been talking, weighing options of what course to take in > dealing with moving forward-- with the goal of both offering both stability > and the choice to have the latest functionality and bug

Re: Bugtracker DBD::mysql

On Tuesday 14 November 2017 10:56:58 Michiel Beijen wrote: > Hi Pali, > > On Mon, Nov 13, 2017 at 6:18 PM, <p...@cpan.org> wrote: > > And I would suggest to disable issue tracker on github as primary bug > > tracker (according to DBD::mysql documentation) is on R

Re: DBD::mysql next steps

And I would suggest to disable issue tracker on github as primary bug tracker (according to DBD::mysql documentation) is on RT and also probably all problems are reported there. The worst thing which can be is to have two independent bug trackers, which is current situation.

Re: DBD::mysql next steps

On Friday 10 November 2017 10:13:55 Patrick M. Galbraith wrote: > Greetings all! > > Michiel and I have been talking, weighing options of what course to take in > dealing with moving forward-- with the goal of both offering both stability > and the choice to have the latest functionality and bug

Re: DBD::mysql path forward

Technical: Reason why it does not help nor solve the main problem: Due to internals, DBD::mysql pseudo-randomly decide if input bind variable is encoded to UTF-8 or not. And do it independently of how is option enable_utf8 configured. As we know there are applications which misuse this internal.

Re: DBD::mysql path forward

On Friday 10 November 2017 10:09:59 demerphq wrote: > Pali is there a concise summary of what we are arguing about here? Short summary: 1. There are applications which misuse perl and DBD::mysql internals to pass blob or utf-8 text data from perl to MySQL database. We were not aw

Re: DBD::mysql path forward

D::mysql (as libmysqlclient application) stopped working, > > because is misusing internals of C structures? > > Pali, I wanted to give you some feedback on this thread. I have been > monitoring this discussion for some time. My $workplace probably has > one of the largest

Re: DBD::mysql path forward

On Friday 10 November 2017 07:59:05 Michiel Beijen wrote: > I'll stick with my earlier proposal - I'll propose to go back to the > *current* latest DBD::mysql release which does not break backcompat > for our users; add the patches that we discarded when we rolled back > one by one, such as

Re: DBD::mysql path forward

I do not understand what (and how) your proposal with =2 solve. Probably nothing and people would again start after final release again complaining... On Friday 10 November 2017 09:24:35 Night Light wrote: > Forking would take away my concerns (thank you all for suggesting that) but > one thing

Re: DBD::mysql path forward

; >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 ma

Re: DBD::mysql path forward

On Thursday 09 November 2017 13:01:19 H.Merijn Brand wrote: > On Thu, 9 Nov 2017 12:32:00 +0100, p...@cpan.org wrote: > > > > Satisfy the above - and you do get the privilege of being a maintainer > > > of a central module with 15+ years of history. > > > > Why should I be interested in

Re: DBD::mysql path forward

odule 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.htm

Re: DBD::mysql path forward

Hi! I'm responding below. On Tuesday 07 November 2017 13:19:23 Darren Duncan wrote: > Patrick and Pali, each of you please respond to the lists to confirm that > what I say below is what you also understand is the primary plan, and if > not, then say why not; in prior discussion I r

Re: DBD::mysql path forward

On Tuesday 26 September 2017 14:20:33 Night Light wrote: > That's a nifty function. Good to know that it can be reversed. UTF-8 encode is a function which for any number from the range 0..1114111 assign unique sequence of the numbers 0..255. Therefore this function has a well defined inverse -

Re: DBD::mysql path forward

On Tuesday 26 September 2017 14:20:33 Night Light wrote: > I noticed that it was mentioned in DBD::mysql # 117 that DBD::mysql does > know that a column in a returned resultset is a BLOB. For returned values via MySQL protocol, there are two different and independent things: SQL type and

Re: DBD::mysql path forward

Hello, may I ask how this situation differs from upgrading DBD::Pg to version 3.3.0 or DBD::SQLite to version 1.43_04? What you are writing there basically affects also DBD::SQLite... And version 1.43_04 was already released... On Tuesday 19 September 2017 14:46:09 Night Light wrote: > Dear

Re: DBD::mysql path forward

at > >> with a commit to master that changes the DBD::mysql version to > >> 5.0. > > > > If everybody agree with this step, I can prepare pull request which > > revert tree to this state, plus re-apply/rebase commits which were > > newly accepted. I prepare

Re: DBD::mysql path forward

On Thursday 14 September 2017 08:21:42 H.Merijn Brand wrote: > On Wed, 13 Sep 2017 13:27:58 -0700, Darren Duncan > wrote: > > > On 2017-09-13 12:58 PM, Dan Book wrote: > > > On Wed, Sep 13, 2017 at 3:53 AM, Peter Rabbitson wrote: > > > > > > On 09/12/2017 07:12 PM,

Re: DBD::mysql path forward

On Tuesday 12 September 2017 11:32:36 Darren Duncan wrote: > On 2017-09-12 11:05 AM, p...@cpan.org wrote: > >On Tuesday 12 September 2017 19:00:59 Darren Duncan wrote: > >>I strongly recommend that another thing happen, which is > >>re-versioning DBD::mysql to 5.0. > >> > >>1. From now on,

Re: DBD::mysql path forward

; > Thank you for the great discussion! > > Patrick > > On 9/12/17 2:05 PM, p...@cpan.org wrote: > >On Tuesday 12 September 2017 19:00:59 Darren Duncan wrote: > >>On 2017-09-12 8:54 AM, Dan Book wrote: > >>>On Tue, Sep 12, 2017 at 11:04 AM, Patrick M. Galbraith wrot

Re: DBD::mysql path forward

On Tuesday 12 September 2017 19:00:59 Darren Duncan wrote: > On 2017-09-12 8:54 AM, Dan Book wrote: > > On Tue, Sep 12, 2017 at 11:04 AM, Patrick M. Galbraith wrote: > > Pali, > > Yes, I agree, we'll have to create a fork pre revert and stop > > accepting PR

Re: DBD::mysql path forward

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.

Re: DBD::mysql path forward

eases like it was between 4.041 and 4.042. Any comments from other people about this idea? On Tuesday 12 September 2017 17:04:18 Patrick M. Galbraith wrote: > Pali, > > Yes, I agree, we'll have to create a fork pre revert and stop > accepting PRs > > How might we allow people time to

Re: DBD::mysql path forward

On Tuesday 12 September 2017 05:40:31 Patrick M. Galbraith wrote: > Hi all, > > After talking to Pali and looking at how other drivers have handled the > issue, the best way forward will be to deal with solving the UTF-8 issue > correctly as was attempted in May. This will be a p

Re: Fork DBD::mysql

first email in this thread. > Author: Michiel Beijen <michiel.bei...@gmail.com> 2017-06-29 11:25:48 > Committer: Michiel Beijen <michiel.bei...@gmail.com> 2017-06-29 11:30:07 > Tags: 4.043 > Parent: 1ece6b4b8630a1cf348373aa41cbe5f748dcd62a (Merge pull request #137 > from pali/versions) > Branch: remotes/origin/master > Follows: 4.042 > Precedes: > > New version 4.043 - the same as 4.041

Re: Fork DBD::mysql

On Tuesday 29 August 2017 22:08:09 Dan Book wrote: > Though the reversion was made with good intentions of preserving back > compat in the short term, it was accompanied by a promise of reapplying the > many important fixes that were reverted ( >

Re: Fork DBD::mysql

On Monday 28 August 2017 09:19:46 Darren Duncan wrote: > While a fork may be the best short term fix, as keeping up with security > issues is important, I honestly believe that the best fix is to migrate to > Postgres as soon as you can. It is not as easy as it could appear. And also in some

Re: [External] Fork DBD::mysql

Then users of MySQL would stay with DBD::mysql and they would not have fixed DBD driver. We were thinking about choosing DBD::mariadb name for our fork. But without dropping MySQL support, so also MySQL users could benefit from it. On Monday 28 August 2017 18:08:20 Daniël van Eeden wrote: > What

Fork DBD::mysql

Hello, 2 months passed since two security problems related to DBD::mysql were reported, namely CVE-2017-10789 and CVE-2017-10788. Looking at the DBD::mysql github project page and RT bugtracker, it can be seen that nothing has happened for 2 months. Some people are asking or waiting for reported