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 anti
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 wil
On 11/11/2017 01:13, 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 a
You cannot go further without either breaking existing code.
You *can* fix the code in a fork. This gives people the of switching to the
fork when *they* want to. Or don’t switch.
Seems to me forking is the only way forward.
Just my 2c worth, having been exposed to these shenanigans of point
I followed the discussion silently so far as I‘m not a user of DBD:mysql.
If the changes are breaking I‘d also think a new distribution is the way to go.
What about DBD::MariaDB as that‘s the name of the OpenSource version these days?
Best regards, Alex
> Am 10.11.2017 um 07:16 schrieb Darren Dun
This kind of stuff is trivial in Perl. You've chosen a good language.
my $url =~ s|/bar$||;
...Which means: "Find any occurence of "/bar" at the very end of the URL
and replace it
with a nothing. This is called a "regex" ( short for "regular
expression" ). We usually do regexes with forward
I agree in principle with Patrick's plan.
My strong recommendation for continuing development under a different module
name was based on the assumption (but not the knowledge) that the Unicode/Blob
problems were rooted in the DBD::mysql codebase in such a way that they blocked
the ability to u
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 i
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. Ca
You repeatedly expressed that you are not willing to maintain this module.
This practically means that code is being asked to be released but somebody
else needs to maintain it.
Suggestions to change this code are next to that ignored. Questions to park
the blocking encoding issue and at least go t
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
aware of them
hello dear perl-experts,
I'm pretty new to Programming and OO programming especially.
Nonetheless, I'm trying to get done a very simple Spider for web crawling.
the script below - is what i got to work
it runs nicely : now i want to modify the script a bit - tailoring and
tinkering is the way t
On Friday 10 November 2017 13:40:40 demerphq wrote:
> On 10 November 2017 at 13:11, wrote:
> > Should DBD::mysql maintainers now starting complaining to Oracle and
> > MariaDB, that they must revert their changes in MySQL and MariaDB, just
> > because DBD::mysql (as libmysqlclient application) st
On 10 November 2017 at 13:11, wrote:
> Should DBD::mysql maintainers now starting complaining to Oracle and
> MariaDB, that they must revert their changes in MySQL and MariaDB, just
> because DBD::mysql (as libmysqlclient application) stopped working,
> because is misusing internals of C structur
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 testing
On 9 November 2017 at 15:45, wrote:
> On Thursday 09 November 2017 14:26:01 Peter Rabbitson wrote:
>> 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
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 po
Forking would take away my concerns (thank you all for suggesting that) but
one thing pops into my mind:
A decision to fork a mature module is not a light decision and should only
be considered as a last resort (when ran out of all options).
So far it is all based on the opinion of only one develop
18 matches
Mail list logo
