MySQL IV vs PV

[James Cloos]

Is there anything in a db handle or statement handle one use to know
whether the running instance of DBD::MySQL will return integer columns
as IV?

I'm adding some code to a layer atop DBI which will force IV (via +=0),
but want to avoid doing that were it is not required.

The particular code path serializes the returned rows via JSON::XS,
hense the need.

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

Re: DBD::mysql next steps

[pali]

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

[Patrick M. Galbraith]

Me too!

I look forward to getting pull requests reviewed and in the driver as 
well as get your UTF-8 work in per my previous email. We can use all the 
help we can get.


regards,

Patrick

On 11/11/17 3:53 AM, p...@cpan.org wrote:

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 fixes as well as
give contributors the opportunity to be part of overall improvements to the
driver.

What we are going to do is:

Add to the connection the ability to turn on proper UTF handling with
'mysql_enable_proper_unicode'. This gives the user volition the option to 
knowingly
toggle whether they want the new functionality and understand that
data structures returned or accepted by the driver might be different
than without this setting.

The other options had their merits, but we think this will solve the issue
while keeping the driver unified and prevent divergence.

Thank you for your input over the last couple months-- we look forward to
moving ahead!

Patrick and Michiel

Great! Thank you very much, I'm waiting for a new action which would
bring DBD::mysql back to the active development.

RE: DBD::mysql next steps

[Curtis Leach]

Just a thought, also add another flag to explicitly use the buggy code even if it is the default.  That option would just suppress the warnings for now. ('mysql_enable_depreciated_unicode' vs 'mysql_enable_proper_unicode')

If the warnings are annoying enough it gives the users of the "depreciated" code base an incentive to review their code to at least turn off the warnings and start thinking about fixing their code.

Then eventually if you use the "depreciated",  or don't use the "proper" option, you could just abort the code with an error message saying to downgrade DBD::mysql  to a specific release.   It should be fairly strait forward to downgrade DBD::mysql at that point.



  
  


  Curtis Leach  |  
  Lead EngineerO 
  702-494-4562    One Harrah's Court | Las Vegas, NV 
  89119www.caesars.com
  

 

-Original Message-
From: Darren Duncan [mailto:dar...@darrenduncan.net] 
Sent: Friday, November 10, 2017 6:39 PM
To: dbi-users@perl.org
Subject: Re: DBD::mysql next steps

On 2017-11-10 5:58 PM, Dan Book wrote:
> On Fri, Nov 10, 2017 at 8:43 PM, Noel Butler wrote:
> Given that things are only ever going to move forward with my/maria-sql
> would it not be better to enable this by default, and have a "disable"
> setting for those who want to run something of antiques?
>
> Because in years to come there will only ever be the modern versions and
> you;ll have to change default behavior then anyway, but since that time is
> mostly here now, it makes more sense to enable it by default.
>
> No, this whole issue came about because existing code requires 
> modification to continue working. Requiring a new option to be set to 
> enable old behavior would cause the same problem. Backcompat is "forever".

Yes, exactly.

However, other things we CAN do include:

1.  Prominently document the new switch with the strong recommendation that people flip it on by default in new code just as part of good housekeeping. 
Basically in the same vein as recommending use-strict or use-warnings without turning them on by default.  This also means that all code examples for DBD::mysql should make sure to include setting the flag on.

2.  After a reasonable but relatively short delay following the first version with this switch, make DBD::mysql issue warnings when it is used without turning that switch on.  That should draw the attention of people that they need to update their code to work more properly but without actually breaking anything (unless someone uses warnings with FATAL, but then they asked for it).  I say have a delay so that people who pay attention and would fix their code soon don't have reams of warnings appearing in their server logs.  Although in general to keep the warning count down it could probably just be issued the first time a connection handle is used without the flag.

3.  Make sure that at least the public or known Perl code using DBD::mysql and has reasonable control over use of the handle would turn the flag on.

So Darkpan is mainly handled by #1 and #2 such as it can be.

-- Darren Duncan