Re: Bring AnyData / DBD::AnyData back to work with modern DBI
Am 13.11.2014 um 17:18 schrieb Jens Rehsack rehs...@cpan.org: Am 13.11.2014 um 16:47 schrieb Peter Rabbitson rab...@rabbit.us: On 11/13/2014 04:07 PM, Jens Rehsack wrote: ... political correctness guards (sorry, I do not see any advantage in the don't ever do this because it's forbidden in general). You need to clarify what you mean, language seems to be getting in the way. What do you perceive as political correctness, and what do you perceive as forbidden ? I know that in general an existing (used) API shouldn't be removed without good reason. That's why - in particular case - the users of AnyData should say whether they want a fixed AnyData relying on changed API or stick at the current existing darkpan ranks. I perceive as political correctness you're enforcement of not kicking an existing module (working or not) out of the way in favor of a working successor. [4:21pm][Sno]: Tux: refresh AnyData ... how proceed ;) [4:21pm]Tux: hit me [4:21pm][Sno]: why is Alt::AnyData::DBITEAM that bad? [4:23pm]Tux: would you find that if you were looking for it? [4:23pm]Tux: DBIx::AnyData ? [4:25pm][Sno]: Tux: the idea is to have a new module on the one hand without overlaying existing namespace because of hidden incompatibilities [4:25pm]Tux: so the old one is DBD::AnyData [4:25pm][Sno]: and being able to use it out-of-the-box with DBI as DBD::AnyData or AnyData as meant with public API [4:26pm][Sno]: there're 2 modules - AnyData and DBD::AnyData (both old) [4:26pm]Tux: ahhh (coin drops) [4:26pm]Tux: Alt::AnyData::DBITEAM is the API? [4:27pm][Sno]: I adapted the name from https://metacpan.org/release/Alt-common-sense-TOBYINK [4:28pm]Tux: ad*o*pted [4:28pm][Sno]: point [4:28pm]Tux: now that I read it, I can accept that name [4:29pm][Sno]: looks to me as if Toby distributes a new common::sense but doesn't index it [4:31pm][Sno]: we would distribute an Alt::AnyData::DBITEAM which deploys an AnyData and an DBD::AnyData on with (what should it deploy for co-existence?) [4:31pm]Tux: no answer [4:32pm][Sno]: is there a sane way distributing AnyData2/DBD::AnyData2 and on top of that an Alt::AnyData::DBITEAM which adopts the namespaces? [4:32pm]Tux: .o( kinda fun to see how different minds follow different paths in development ) [4:33pm]Tux: yes, see DDS for Data::Dump::Streamer [4:33pm]Tux: or DP for Data::Peek [4:33pm]Tux: you can *ask* the user if installing the (new) names as alias for the better version is ok [4:44pm]Tux: To expand on that: *my* way would be to implement the two new modules first and rename them into whatever is accepted just before releasing them [4:44pm]Tux: I want to have fun. name-wars are not fun [4:46pm][Sno]: Tux: sorry - phone, plumber, ... [4:47pm][Sno]: I think the option should be there by providing 2nd dist which just overlays for the namespace [4:47pm][Sno]: maybe ribasushi or timbunce (who both originally voted for new namespace) have an idea regarding that? [4:49pm][Sno]: but I don't know how an AnyData.pm could look like which just sucks in AnyData2.pm (similar for DBD::AnyData) Ideas? Comments? Cheers -- Jens Rehsack rehs...@gmail.com
Re: Bring AnyData / DBD::AnyData back to work with modern DBI
My impression was that there was a risk of breaking existing users apps. If that can be avoided then great, and keeping the name would be best. Tim. On Thu, Nov 13, 2014 at 07:12:33AM +0100, Jens Rehsack wrote: Am 12.11.2014 um 16:14 schrieb Tim Bunce tim.bu...@pobox.com: Perhaps the module name should be changed. Why? Let me just talk about the reason to keep and the consequence to change. Reason to keep: People continuous ask me about AnyData / DBD::AnyData and send me fiddly patches hacking in the module, complain about working around compat issues etc. So what I currently know: every AnyData / DBD::AnyData user makes adoptions to the projects. Consequence to change: My requirements are easy: I need a DBD scanning a directory for files, opening the files and return the file name plus the :, separated fields (some optional, some key-value pairs) for each line. Hacking a new DBD would mean to me: clone DBD::CSV and adopt the parser. Why did I decide for AnyData? Because the idea behind AnyData matches the requirements I have. It will be easier to find another consultant having knowledge about DBI and (new) AnyData than DBI, private DBD and the patch-supporting pkg-manager we'll use to add private prefix :) Once we start local CPAN module patches, the motivation to contribute instead of hacking locally is reduced significantly (typical project flow - once a direction is chosen, it's fixated ...) Beside the argument to keep an existing (working!) API for people who using it (which practically doesn't exists for AnyData/DBD::AnyData), why I should do a new DBD? Jens Tim. On Wed, Nov 12, 2014 at 10:33:20AM +0100, Jens Rehsack wrote: Hi, for a recent project we identified DBD::AnyData as best concept to do a client's job ;) So there is a tuit to do the groundwork for bringing AnyData back to modern DBI interface around DBI::DBD::SqlEngine based drivers. Last weeks I spent some time digging into AnyData itself to identify interfaces to touch for harmonization with the data_sources concept in DBI::DBD::SqlEngine (DBD::File). This mail is intended to share the results and present a concept for resurrection of the (more or less) dead module. For that reason, I CC'ed some people who got in touch with me over last years regarding AnyData and/or DBD::AnyData - to give them a chance to contribute. At first the situation as it is: We (dbd-file-team, in this special case more or less Merijn and myself) identified most of AnyData and DBD::AnyData as being dead and nearly unusable in environments with modern Perl and up-to-date CPAN modules. The module is grown, bloated (no judgement for the time of writing), inconsistent and kind of self-contained (no reasonable API to outside). AnyData::Storage::TieHash is not a storage class, it's a miniature Tie::Hash::DBD with own query processing (parallel to DBI's SqlEngines and weird automatisms). I stop here to avoid starting a flame-war - the intension is to improve, not to blame. So where is the future of AnyData? From my point of view, upcoming AnyData / DBD::AnyData shall be reduced to the max. That means: no embedded adTie, no complex logic in frontend to deal with grown backends. Clean API for format-parsers, clean API for storage harmonized with DBI::DBD::SqlEngine::TableSource and DBI::DBD::SqlEngine::DataSource. Consequently, upcoming releases of AnyData will depend on DBI. Format-Parsers will be written using DBD::CSV and DBD::DBM as guide (simple get_record, put_record etc. wrapper). To provide a tied hash again, DBD::AnyData will be bundled with AnyData (instead of two distributions in past) and Tie::Hash::DBD or Tie::DBI will be used. adConvert, adDump and adExport are special cases of features already provided by SQL::Statement and will be re-implemented by using that functionality. That all means, future API might be puzzled using roles to avoid strong requirements (Moo or Role::Tiny isn't decided yet) and unfortunately most of existing format-parsers in DarkPAN might require a rewrite. I hope the AnyData resurrection will help to reduce maintaining costs for future and apologize here and now for resulting extra effort when updating. Best regards -- Jens Rehsack pkgsrc, Perl5 rehs...@cpan.org cpanid: REHSACK -- Jens Rehsack rehs...@gmail.com
Re: Bring AnyData / DBD::AnyData back to work with modern DBI
Am 13.11.2014 um 14:37 schrieb Tim Bunce tim.bu...@pobox.com: My impression was that there was a risk of breaking existing users apps. If that can be avoided then great, and keeping the name would be best. Neither, nor :( They're already broken. The intension is, to pick them up and lead them to new meadow areas without broken module(s) :) Jens Tim. On Thu, Nov 13, 2014 at 07:12:33AM +0100, Jens Rehsack wrote: Am 12.11.2014 um 16:14 schrieb Tim Bunce tim.bu...@pobox.com: Perhaps the module name should be changed. Why? Let me just talk about the reason to keep and the consequence to change. Reason to keep: People continuous ask me about AnyData / DBD::AnyData and send me fiddly patches hacking in the module, complain about working around compat issues etc. So what I currently know: every AnyData / DBD::AnyData user makes adoptions to the projects. Consequence to change: My requirements are easy: I need a DBD scanning a directory for files, opening the files and return the file name plus the :, separated fields (some optional, some key-value pairs) for each line. Hacking a new DBD would mean to me: clone DBD::CSV and adopt the parser. Why did I decide for AnyData? Because the idea behind AnyData matches the requirements I have. It will be easier to find another consultant having knowledge about DBI and (new) AnyData than DBI, private DBD and the patch-supporting pkg-manager we'll use to add private prefix :) Once we start local CPAN module patches, the motivation to contribute instead of hacking locally is reduced significantly (typical project flow - once a direction is chosen, it's fixated ...) Beside the argument to keep an existing (working!) API for people who using it (which practically doesn't exists for AnyData/DBD::AnyData), why I should do a new DBD? Jens Tim. On Wed, Nov 12, 2014 at 10:33:20AM +0100, Jens Rehsack wrote: Hi, for a recent project we identified DBD::AnyData as best concept to do a client's job ;) So there is a tuit to do the groundwork for bringing AnyData back to modern DBI interface around DBI::DBD::SqlEngine based drivers. Last weeks I spent some time digging into AnyData itself to identify interfaces to touch for harmonization with the data_sources concept in DBI::DBD::SqlEngine (DBD::File). This mail is intended to share the results and present a concept for resurrection of the (more or less) dead module. For that reason, I CC'ed some people who got in touch with me over last years regarding AnyData and/or DBD::AnyData - to give them a chance to contribute. At first the situation as it is: We (dbd-file-team, in this special case more or less Merijn and myself) identified most of AnyData and DBD::AnyData as being dead and nearly unusable in environments with modern Perl and up-to-date CPAN modules. The module is grown, bloated (no judgement for the time of writing), inconsistent and kind of self-contained (no reasonable API to outside). AnyData::Storage::TieHash is not a storage class, it's a miniature Tie::Hash::DBD with own query processing (parallel to DBI's SqlEngines and weird automatisms). I stop here to avoid starting a flame-war - the intension is to improve, not to blame. So where is the future of AnyData? From my point of view, upcoming AnyData / DBD::AnyData shall be reduced to the max. That means: no embedded adTie, no complex logic in frontend to deal with grown backends. Clean API for format-parsers, clean API for storage harmonized with DBI::DBD::SqlEngine::TableSource and DBI::DBD::SqlEngine::DataSource. Consequently, upcoming releases of AnyData will depend on DBI. Format-Parsers will be written using DBD::CSV and DBD::DBM as guide (simple get_record, put_record etc. wrapper). To provide a tied hash again, DBD::AnyData will be bundled with AnyData (instead of two distributions in past) and Tie::Hash::DBD or Tie::DBI will be used. adConvert, adDump and adExport are special cases of features already provided by SQL::Statement and will be re-implemented by using that functionality. That all means, future API might be puzzled using roles to avoid strong requirements (Moo or Role::Tiny isn't decided yet) and unfortunately most of existing format-parsers in DarkPAN might require a rewrite. I hope the AnyData resurrection will help to reduce maintaining costs for future and apologize here and now for resulting extra effort when updating. Best regards -- Jens Rehsack pkgsrc, Perl5 rehs...@cpan.org cpanid: REHSACK -- Jens Rehsack rehs...@gmail.com -- Jens Rehsack rehs...@gmail.com
Re: Bring AnyData / DBD::AnyData back to work with modern DBI
On Thu, 13 Nov 2014 14:58:55 +0100, Jens Rehsack rehs...@cpan.org wrote: Am 13.11.2014 um 14:37 schrieb Tim Bunce tim.bu...@pobox.com: My impression was that there was a risk of breaking existing users apps. If that can be avoided then great, and keeping the name would be best. Neither, nor :( They're already broken. Beyond repair (currently) The intension is, to pick them up and lead them to new meadow areas without broken module(s) :) And we will all rejoice Jens -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.21 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ pgpamUiZmhzlj.pgp Description: OpenPGP digital signature
Re: Bring AnyData / DBD::AnyData back to work with modern DBI
On 11/13/2014 07:12 AM, Jens Rehsack wrote: Reason to keep: People continuous ask me about AnyData / DBD::AnyData and send me fiddly patches hacking in the module, complain about working around compat issues etc. So what I currently know: every AnyData / DBD::AnyData user makes adoptions to the projects. On 11/13/2014 02:58 PM, Jens Rehsack wrote: Am 13.11.2014 um 14:37 schrieb Tim Bunce tim.bu...@pobox.com: My impression was that there was a risk of breaking existing users apps. If that can be avoided then great, and keeping the name would be best. Neither, nor :( They're already broken. everything is already broken contradicts people are using it and sending me patches. It can't be both ways It either is completely unused and nobody depends on it OR The module is heavily customized and worked around in tons of darkpan In the later case imnsho the module needs to be left alone. See Class::DBI for exactly this sort of case.
Re: Bring AnyData / DBD::AnyData back to work with modern DBI
Am 13.11.2014 um 15:08 schrieb Peter Rabbitson rab...@rabbit.us: On 11/13/2014 07:12 AM, Jens Rehsack wrote: Reason to keep: People continuous ask me about AnyData / DBD::AnyData and send me fiddly patches hacking in the module, complain about working around compat issues etc. So what I currently know: every AnyData / DBD::AnyData user makes adoptions to the projects. On 11/13/2014 02:58 PM, Jens Rehsack wrote: Am 13.11.2014 um 14:37 schrieb Tim Bunce tim.bu...@pobox.com: My impression was that there was a risk of breaking existing users apps. If that can be avoided then great, and keeping the name would be best. Neither, nor :( They're already broken. everything is already broken contradicts people are using it and sending me patches. It can't be both ways It either is completely unused and nobody depends on it OR The module is heavily customized and worked around in tons of darkpan In the later case imnsho the module needs to be left alone. See Class::DBI for exactly this sort of case. I say it once again: The only way to leave it alone is to walk another way (not touching AnyData at all). That will result in no solution for anyone but political correctness guards (sorry, I do not see any advantage in the don't ever do this because it's forbidden in general). Cheers -- Jens Rehsack rehs...@gmail.com
Re: Bring AnyData / DBD::AnyData back to work with modern DBI
On 11/13/2014 04:07 PM, Jens Rehsack wrote: ... political correctness guards (sorry, I do not see any advantage in the don't ever do this because it's forbidden in general). You need to clarify what you mean, language seems to be getting in the way. What do you perceive as political correctness, and what do you perceive as forbidden ?
Re: Bring AnyData / DBD::AnyData back to work with modern DBI
Am 13.11.2014 um 16:47 schrieb Peter Rabbitson rab...@rabbit.us: On 11/13/2014 04:07 PM, Jens Rehsack wrote: ... political correctness guards (sorry, I do not see any advantage in the don't ever do this because it's forbidden in general). You need to clarify what you mean, language seems to be getting in the way. What do you perceive as political correctness, and what do you perceive as forbidden ? I know that in general an existing (used) API shouldn't be removed without good reason. That's why - in particular case - the users of AnyData should say whether they want a fixed AnyData relying on changed API or stick at the current existing darkpan ranks. I perceive as political correctness you're enforcement of not kicking an existing module (working or not) out of the way in favor of a working successor. Cheers -- Jens Rehsack rehs...@gmail.com
Re: Bring AnyData / DBD::AnyData back to work with modern DBI
Perhaps the module name should be changed. Tim. On Wed, Nov 12, 2014 at 10:33:20AM +0100, Jens Rehsack wrote: Hi, for a recent project we identified DBD::AnyData as best concept to do a client's job ;) So there is a tuit to do the groundwork for bringing AnyData back to modern DBI interface around DBI::DBD::SqlEngine based drivers. Last weeks I spent some time digging into AnyData itself to identify interfaces to touch for harmonization with the data_sources concept in DBI::DBD::SqlEngine (DBD::File). This mail is intended to share the results and present a concept for resurrection of the (more or less) dead module. For that reason, I CC'ed some people who got in touch with me over last years regarding AnyData and/or DBD::AnyData - to give them a chance to contribute. At first the situation as it is: We (dbd-file-team, in this special case more or less Merijn and myself) identified most of AnyData and DBD::AnyData as being dead and nearly unusable in environments with modern Perl and up-to-date CPAN modules. The module is grown, bloated (no judgement for the time of writing), inconsistent and kind of self-contained (no reasonable API to outside). AnyData::Storage::TieHash is not a storage class, it's a miniature Tie::Hash::DBD with own query processing (parallel to DBI's SqlEngines and weird automatisms). I stop here to avoid starting a flame-war - the intension is to improve, not to blame. So where is the future of AnyData? From my point of view, upcoming AnyData / DBD::AnyData shall be reduced to the max. That means: no embedded adTie, no complex logic in frontend to deal with grown backends. Clean API for format-parsers, clean API for storage harmonized with DBI::DBD::SqlEngine::TableSource and DBI::DBD::SqlEngine::DataSource. Consequently, upcoming releases of AnyData will depend on DBI. Format-Parsers will be written using DBD::CSV and DBD::DBM as guide (simple get_record, put_record etc. wrapper). To provide a tied hash again, DBD::AnyData will be bundled with AnyData (instead of two distributions in past) and Tie::Hash::DBD or Tie::DBI will be used. adConvert, adDump and adExport are special cases of features already provided by SQL::Statement and will be re-implemented by using that functionality. That all means, future API might be puzzled using roles to avoid strong requirements (Moo or Role::Tiny isn't decided yet) and unfortunately most of existing format-parsers in DarkPAN might require a rewrite. I hope the AnyData resurrection will help to reduce maintaining costs for future and apologize here and now for resulting extra effort when updating. Best regards -- Jens Rehsack pkgsrc, Perl5 rehs...@cpan.org cpanid: REHSACK
Re: Bring AnyData / DBD::AnyData back to work with modern DBI
Am 12.11.2014 um 16:14 schrieb Tim Bunce tim.bu...@pobox.com: Perhaps the module name should be changed. Why? Let me just talk about the reason to keep and the consequence to change. Reason to keep: People continuous ask me about AnyData / DBD::AnyData and send me fiddly patches hacking in the module, complain about working around compat issues etc. So what I currently know: every AnyData / DBD::AnyData user makes adoptions to the projects. Consequence to change: My requirements are easy: I need a DBD scanning a directory for files, opening the files and return the file name plus the :, separated fields (some optional, some key-value pairs) for each line. Hacking a new DBD would mean to me: clone DBD::CSV and adopt the parser. Why did I decide for AnyData? Because the idea behind AnyData matches the requirements I have. It will be easier to find another consultant having knowledge about DBI and (new) AnyData than DBI, private DBD and the patch-supporting pkg-manager we'll use to add private prefix :) Once we start local CPAN module patches, the motivation to contribute instead of hacking locally is reduced significantly (typical project flow - once a direction is chosen, it's fixated ...) Beside the argument to keep an existing (working!) API for people who using it (which practically doesn't exists for AnyData/DBD::AnyData), why I should do a new DBD? Jens Tim. On Wed, Nov 12, 2014 at 10:33:20AM +0100, Jens Rehsack wrote: Hi, for a recent project we identified DBD::AnyData as best concept to do a client's job ;) So there is a tuit to do the groundwork for bringing AnyData back to modern DBI interface around DBI::DBD::SqlEngine based drivers. Last weeks I spent some time digging into AnyData itself to identify interfaces to touch for harmonization with the data_sources concept in DBI::DBD::SqlEngine (DBD::File). This mail is intended to share the results and present a concept for resurrection of the (more or less) dead module. For that reason, I CC'ed some people who got in touch with me over last years regarding AnyData and/or DBD::AnyData - to give them a chance to contribute. At first the situation as it is: We (dbd-file-team, in this special case more or less Merijn and myself) identified most of AnyData and DBD::AnyData as being dead and nearly unusable in environments with modern Perl and up-to-date CPAN modules. The module is grown, bloated (no judgement for the time of writing), inconsistent and kind of self-contained (no reasonable API to outside). AnyData::Storage::TieHash is not a storage class, it's a miniature Tie::Hash::DBD with own query processing (parallel to DBI's SqlEngines and weird automatisms). I stop here to avoid starting a flame-war - the intension is to improve, not to blame. So where is the future of AnyData? From my point of view, upcoming AnyData / DBD::AnyData shall be reduced to the max. That means: no embedded adTie, no complex logic in frontend to deal with grown backends. Clean API for format-parsers, clean API for storage harmonized with DBI::DBD::SqlEngine::TableSource and DBI::DBD::SqlEngine::DataSource. Consequently, upcoming releases of AnyData will depend on DBI. Format-Parsers will be written using DBD::CSV and DBD::DBM as guide (simple get_record, put_record etc. wrapper). To provide a tied hash again, DBD::AnyData will be bundled with AnyData (instead of two distributions in past) and Tie::Hash::DBD or Tie::DBI will be used. adConvert, adDump and adExport are special cases of features already provided by SQL::Statement and will be re-implemented by using that functionality. That all means, future API might be puzzled using roles to avoid strong requirements (Moo or Role::Tiny isn't decided yet) and unfortunately most of existing format-parsers in DarkPAN might require a rewrite. I hope the AnyData resurrection will help to reduce maintaining costs for future and apologize here and now for resulting extra effort when updating. Best regards -- Jens Rehsack pkgsrc, Perl5 rehs...@cpan.org cpanid: REHSACK -- Jens Rehsack rehs...@gmail.com
