Re: SQL::Parser schema patches
Hi Gonzalo, > Am 21.07.2015 um 15:29 schrieb Gonzalo Barco : > > Hi, > > A work collegue has made some mods to SQL::Parser and is eager to commit the > to the official code base. The patches should be rebased to latest release and should have tests (either to prove what fails before or what feature now works better/correctly) for quick goal. The patches must not cause existing tests to fail (regression). > Could we send a patch via mail? You can send them via e-Mail, but please not to my private e-Mail. Send them to dbi-dev@ mailing list, RT bug-tracker or github issue tracker. Best regards, -- Jens Rehsack - rehs...@gmail.com
AnyData2-0.001 released
Hi, seems I need fix some tests to skip when prereqs aren't satisfied, but beside that - an AnyData2 is ready to be used. For DBD::AnyData2 DBI-1.634 is required - it's ready and waits for DBI uploads. Any plans there, Tim? Cheers -- Jens Rehsack - rehs...@gmail.com
Released SQL::Statement 1.407
Hi, it was silent around SQL::Statement for a long time ... I uploaded a new release fixing some open bugs this morning. Special thanks is going out to Slaven Rezic for supporting by running tests. Changes log for Perl extension SQL::Statement 1.407 2015-05-26 * Release 1.406_002 without further changes as 1.407 1.406_002 2015-05-22 [Bug fixes] * Fix RT#104579: Redundant argument in sprintf submitted by Slaven Rezić * Fix RT#104589: t/14parse.t fails if Test::Deep is not installed submitted by Slaven Rezić 1.406_001 2015-05-20 [Misc] * clean up Makefile.PL, meta-data and requirements [Bug fixes] * Fix SQL function CONV to use limited number of sane character sets for conversion and rely on Math::Base::Convert instead of own code (suggested by Tom Wyant in RT#100551, thanks Tom) * fix handling of literal identifiers and for every IMPORT rely on literal identifiers to avoid parser errors for column names starting with numbers or similar * fix capability cache: "$class->can(...)" might return undef and therefore inexistent capabilities are queried to often * Fix COUNT(DISTINCT col) without GROUP BY clause (patch submitted by Grant Mathews, thanks Grant) * Fix "parse insert with functions" submitted via GitHub PR#6 by fecundf and RT#96628 * Fix RT#93320: SQL-style comment can not begin inside quotes by Tom Wyant - thanks Tom [Improvements] * reduce blocks and rewrite some inner statements to increase speed of sql command processing Best regards -- Jens Rehsack - rehs...@gmail.com
SQL-Statement 1.406_001 dev-release out for testing
Hi, I recently uploaded a dev-release of SQL-Statement (1.406_001) because of so many (partially exciting patches from community). I hereby kindly ask anybody who's using it to test it whether it works as expected or not. I'm looking forward to release 1.407 at begin of next week when no regressions are introduced. Cheers -- Jens Rehsack - rehs...@gmail.com
[perl5-dbi/dbi] 706609: reflect Changes
Branch: refs/heads/master Home: https://github.com/perl5-dbi/dbi Commit: 706609e89f961924cb419d34ea7c9b1dd9c88f9b https://github.com/perl5-dbi/dbi/commit/706609e89f961924cb419d34ea7c9b1dd9c88f9b Author: Jens Rehsack Date: 2015-05-05 (Tue, 05 May 2015) Changed paths: M Changes Log Message: --- reflect Changes
[perl5-dbi/dbi] 489e67: allow special table classes in meta
Branch: refs/heads/master Home: https://github.com/perl5-dbi/dbi Commit: 489e67f58750c7b8b809f90d862ac5b35a00bed8 https://github.com/perl5-dbi/dbi/commit/489e67f58750c7b8b809f90d862ac5b35a00bed8 Author: Jens Rehsack Date: 2015-03-23 (Mon, 23 Mar 2015) Changed paths: M lib/DBI/DBD/SqlEngine.pm Log Message: --- allow special table classes in meta This has two use-cases: 1) See dbi-dev@ mail from 2015/01/27 - "Table Capabilities / Data Access API" 2) Allow one $dbh (e.g. a DBD::CSV) can deal with tables from another $dbh (e.g. a DBD::DBM) by copying the meta using new_sql_engine_meta and adding the table class to use (undocumented until we found a sane test case) Commit: db550269e8f1017261af64ef2e64a5f664e9d217 https://github.com/perl5-dbi/dbi/commit/db550269e8f1017261af64ef2e64a5f664e9d217 Author: Jens Rehsack Date: 2015-04-13 (Mon, 13 Apr 2015) Changed paths: M lib/DBI/DBD/SqlEngine.pm A t/53sqlengine_adv.t Log Message: --- add a test-case showing PoC of new_sql_engine_meta This adds a final fix and a test showing how to mix between different backends of DBI::DBD::SqlEngine Compare: https://github.com/perl5-dbi/dbi/compare/71dc73bf6cdd...db550269e8f1
Review request and missing API for AnyData2 / DBD::AnyData2
Hi, beside some minor quirks in CSV example and missing examples for fixed width and block-wise data, I consider the stage of AnyData2 as "ready for being released as first shot ...". I have an ok to release the customer parser and backend with AnyData2, too - so there're more examples. Maybe the AnyData2->new should be renamed to AnyData2->parser before shipping ... DBD::AnyData2 can be shipped than, too - thanks to merge of PR's #19 and #20 in DBI it runs fine and can support nasty data structures either. If anyone wants to give it a review before official releasing it: * https://github.com/rehsack/AnyData2 * https://github.com/rehsack/DBD-AnyData2 Both will be the official successors of AnyData and DBD::AnyData - so if there is anything you use today, cry out soon. Cheers -- Jens Rehsack - rehs...@gmail.com
DBI, PR 18
Hi Tim, because I got interrupted the entire day by several events, I took it as a sign to merge my reviewed PR and review the others. https://github.com/perl5-dbi/dbi/pull/18 looks simple and sane to me, any objections to merge it and mention it in Changes? Cheers -- Jens Rehsack - rehs...@gmail.com
Re: AnyData2/DBD::AnyData2 co-maint
> Am 22.04.2015 um 12:21 schrieb H.Merijn Brand : > > On Wed, 22 Apr 2015 12:01:46 +0200, Jens Rehsack > wrote: > >> Hi Merijn, >> >> since Wendy told me yesterday that every new module must (should) >> have a co-maint, > > It was decided upon to be *advisory* for upstream modules: those that > have modules on CPAN that depend on it or where is known that DarkPAN > users have publicly shown that they are using the module. > > The latter is not (yet) visible on any of the current CPAN clients. > > co-maint is not obligatory. certainly not for new modules. Than I misunderstood probably something. Anyway - it might be a good idea, either - for keeping an eye on it or whatsoever :) > FWIW, I am in serious doubt if I want to have anyone co-maint > Text::CSV_XS at all. Come on - I had commit bit for years on repo.or.cz and didn't misuse it in any way. >> could I count on you for upcoming AnyData2 / DBD::AnyData2? > > /me is in serious doubt, as the main purpose of these modules is way > out of my focus area: I never use them. My primary reason to use DBD::CSV from time to time is to keep on track how the users problems look like ;) For the typical problems I solve using it, it's overkill ... You're familiar with the separation of storage / parsing engine, you're familiar with DBI::DBD::SqlEngine and you're more or less familiar with SQL::Statement ... > Do you know of any CPAN author that is using them or has shown interest > in these? That would IMHO be a better choice. Seriously: Nope. Only DarkPAN :( >> I don't want to start on dbi-dev@ a general discussion - so >> AD2: yes or no? Cheers -- Jens Rehsack rehs...@gmail.com
AnyData2/DBD::AnyData2 co-maint
Hi Merijn, since Wendy told me yesterday that every new module must (should) have a co-maint, could I count on you for upcoming AnyData2 / DBD::AnyData2? I don't want to start on dbi-dev@ a general discussion - so AD2: yes or no? Cheers -- Jens Rehsack rehs...@gmail.com
Re: Accidently added CONV in SQL::Statement
Am 05.02.2015 um 18:14 schrieb Peter Rabbitson : > On 02/05/2015 06:11 PM, Jens Rehsack wrote: >> Hi Michael, >> >> I think I will do. Math::Base::Convert with convert for up-to-base64 >> seems to be fine > > I still think providing an arbitrary "up to base64" conversion is a mistake. > Consider the standardized base32 alphabet: > http://en.wikipedia.org/wiki/Base32 I'm also fine with that, thanks for the suggestion. Cheers -- Jens Rehsack rehs...@gmail.com
Re: Accidently added CONV in SQL::Statement
Hi Michael,
I think I will do. Math::Base::Convert with convert for up-to-base64
seems to be fine, whatever MySQL extended - MySQL isn't a standard
I orientate myself or my software ;)
Cheers,
Jens
Am 05.02.2015 um 18:07 schrieb mich...@insulin-pumpers.org:
> Take a look at Math::Base::Convert, maybe that will be helpful. It
> handles VERY large integer numbers efficently instead of returning
> floats, has a larger conversion set, including the missing bases Jens
> asked about, and can be easily expanded to any base. You don't have
> to re-invent the wheel.
>
> Michael
>
>> Sorry for my very late reply.
>>
>> After I wrote the CONV function, I did take much of the code and
>> improved Math::BaseCalc with it. Although, that patch is still stuck
>> in review ( https://github.com/kenahoo/perl-math-basecalc/pull/2).
>>
>> So, I don't mind if the code was stripped out to use a separate module
>> for the conversions. I agree that it's overly complex, since most of
>> these functions should really just be calls to modules or relatively
>> short subs.
>>
>> The CONV function itself wasn't based on SQL-92, but since functions
>> like HEX/BIN/OCT were already needed, I wrote it for those. The name
>> was based on the MySQL function.
>>
>> On Mon, Dec 15, 2014 at 4:40 AM, Jens Rehsack
>> wrote:
>>
>>> Hi,
>>>
>>> during review of SQL::Statement wrt. RT#100551 I realized that the
>>> introduced SQL_FUNCTION_CONV (
>>> https://github.com/perl5-dbi/SQL-Statement/blob/master/lib/SQL/State
>>> ment/Functions.pm#L454) is unnecessary over-complex.
>>>
>>> Since I learned that silent removal of once shipped functionality is
>>> a evil - I'd like to get some suggestions. For existing
>>> implementation I miss a proper documentation of edge-cases: * How is
>>> 1.E converted to octal and why is that necessary in SQL? * Why do
>>> the alphabets lower 63 and 63+ based number differ? * If different
>>> encoding schemes are supported either, why is xnt and b85 missing
>>> and what's about plain ascii?
>>>
>>> From my perspective - unless proper answers are given - the
>>> implementation of SQL_FUNCTION_CONV should be replaced by an easy to
>>> use wrapper around https://metacpan.org/release/Math-Base-Convert to
>>> rely on dedicated tested and approved.
>>>
>>> I started a rough test whether it's possible to keep the existing
>>> API and run into different results for 1st chosen test
>>>{
>>> test => 'conv 2->92',
>>> sql=> "SELECT CONV('101 0100 0111 0110 1011',
>>> 2, 92)", result => [ ['HN(/'] ],
>>>},
>>> Mike's module resulted 'HN)/' - so there seem to be more quirks in
>>> individual S::S solution.
>>>
>>> Any comments?
>>>
>>> Cheers
>>> --
>>> Jens Rehsack
>>> rehs...@gmail.com
>>>
>>>
>>
>>
>> --
>> Brendan Byrd
>> Brendan Byrd
>>
>
>
--
Jens Rehsack
rehs...@gmail.com
(DBD::AnyData2) Table Capabilities / Data Access API
Hi, second issue in DBD::AnyData2 is slightly more complicated ... I added an initial interface to AnyData2::Format (https://github.com/rehsack/AnyData2/blob/master/lib/AnyData2/Format.pm) which has the methods read/write to read and write rows (datasets, records - however). I didn't dig deeply into *::Table API required by SQL engines, I sticked at the initialization parts required by DBD::File & Co. (complete_table_name, etc.). Before this reply, I double checked and seen, we want: * fetch_row * push_row vs. insert_new_row+update_specific_row+delete_one_row I think, this abilities shall be reflected to AnyData2::Format instead of read/write. But the specification says: either table provides push_row or the 3-tuple of specialized API. The table cannot provide the 3-tuple and maps in doubt, because it would replicate the S::S or S::Nano functionality ... A way out is: * clone the stuff and call it a day * we introduce a very low level role technology as Schwern showed for dialects in S::S (https://github.com/perl5-dbi/SQL-Statement/blob/master/lib/SQL/Parser.pm#L289) * more modern role technology (integration into DBD::File or DBI::DBD::SqlEngine?) * directly derive DBD::AnyData2::Table from AnyData2::Format::$foo (open_table can provide a reasonable hack for appropriate tables ...) If we decide for a role, we have to think about the integration into S::S, DBI::DBD::SqlEngine/SQL::Nano and we have to discuss possible ways oof integration with Tim. Cheers -- Jens Rehsack rehs...@gmail.com
(DBD::AnyData2) Table Options
Hi,
first one is a tiny one - and might be a no-brainer ;)
Since AnyData2 is a bit more complicated than CSV and DBM (even if
DBM is on a good way ...), setting options per table is an
important feature for DBD::AnyData2.
I thought about something like:
$dbh->set_table_options( "north", { ad2_archive => ..., ad2_in_progress => ...,
... } );
Both options are for a concrete customer storage backend - so they
might be named "ad2_storage_..." or API should be
$dbh->set_table_options( "east", {
ad2_storage => {
archive => ...,
in_progress => ...,
...
},
ad2_format => {
ignore_missing_trailer => 1,
...
} );
This one should make ad_import() call obsolete - for DBD::DBM we already
have the requirement. As a bonus, such an API could be the first step
in the direction of a dictionary (we already want that feature ^^).
How could such a feature look like for DBD::DBM, especially for dbm_storage
set to berkelydb?
Cheers
--
Jens Rehsack
rehs...@gmail.com
AnyData2 + DBD::AnyData2 - rewrite stucks at API issues ...
Hi, since everyone beside of Tux votes for a rewrite - you get your chance get involved at some API issues. I write for each issue a separate mail to avoid cross-discussion and thread explosion. I also Bcc Markus Uckelmann, because he stated at Niederrhein PM how insane it is to refactor AnyData / DBD::AnyData, because refurbished API needs new namespace. He can jump in and see what those ideas could mean ;) Cheers -- Jens Rehsack rehs...@gmail.com
AnyData2 / DBD::AnyData2
Hi, meanwhile I managed a rough base for AnyData2 - https://github.com/rehsack/AnyData2 To prove the abstraction, fixed width records and array/PerlIO(string) should be added, too. I'm indecisive about bundling mp3-tags and html-tables as AnyData would, I do not see any value there (for bundling!). If the current API seems reasonable and proven (Array, Fixed-Width, ...), the next big question is regarding DBI::DBD::SqlEngine integration: 1) What options are for TableSources / DataSources * https://metacpan.org/pod/distribution/DBI/lib/DBI/DBD/SqlEngine/Developers.pod#DBI::DBD::SqlEngine::TableSource1 * https://metacpan.org/pod/distribution/DBI/lib/DBI/DBD/SqlEngine/Developers.pod#DBI::DBD::SqlEngine::DataSource1 2) Where to join the hierarchy? @DBD::AnyData2::ISA = qw(DBD::File) @DBD::AnyData2::ISA = qw(DBI::DBD::SqlEngine) Cheers -- Jens Rehsack rehs...@gmail.com
Re: Accidently added CONV in SQL::Statement
Am 15.12.2014 um 10:54 schrieb Darren Duncan : > On 2014-12-15 1:40 AM, Jens Rehsack wrote: >> during review of SQL::Statement wrt. RT#100551 I realized that the >> introduced SQL_FUNCTION_CONV >> (https://github.com/perl5-dbi/SQL-Statement/blob/master/lib/SQL/Statement/Functions.pm#L454) >> is unnecessary over-complex. > > Funny, when I first saw that sentence I had thought you added support for > parsing SQL stored procedures/functions. Oh well. -- Darren Duncan Beside of that - no other statement, comment, ...? -- Jens Rehsack rehs...@gmail.com
Accidently added CONV in SQL::Statement
Hi,
during review of SQL::Statement wrt. RT#100551 I realized that the introduced
SQL_FUNCTION_CONV
(https://github.com/perl5-dbi/SQL-Statement/blob/master/lib/SQL/Statement/Functions.pm#L454)
is unnecessary over-complex.
Since I learned that silent removal of once shipped functionality is a evil -
I'd like to get some suggestions.
For existing implementation I miss a proper documentation of edge-cases:
* How is 1.E converted to octal and why is that necessary in SQL?
* Why do the alphabets lower 63 and 63+ based number differ?
* If different encoding schemes are supported either, why is xnt and b85
missing and what's about plain ascii?
From my perspective - unless proper answers are given - the implementation of
SQL_FUNCTION_CONV should be replaced by an easy to use wrapper around
https://metacpan.org/release/Math-Base-Convert to rely on dedicated tested and
approved.
I started a rough test whether it's possible to keep the existing API and run
into different results for 1st chosen test
{
test => 'conv 2->92',
sql=> "SELECT CONV('101 0100 0111 0110 1011', 2, 92)",
result => [ ['HN(/'] ],
},
Mike's module resulted 'HN)/' - so there seem to be more quirks in individual
S::S solution.
Any comments?
Cheers
--
Jens Rehsack
rehs...@gmail.com
[perl5-dbi/dbi] 67fffe: Adding prefix for DBD::Multi per #93204
Branch: refs/heads/master Home: https://github.com/perl5-dbi/dbi Commit: 67fffe6d77658eeb5a4dae40e10456881cf21fdb https://github.com/perl5-dbi/dbi/commit/67fffe6d77658eeb5a4dae40e10456881cf21fdb Author: Dan Wright Date: 2014-12-09 (Tue, 09 Dec 2014) Changed paths: M DBI.pm Log Message: --- Adding prefix for DBD::Multi per #93204 Commit: 175401d9f78758ac133c5abbf392b75df1ccc017 https://github.com/perl5-dbi/dbi/commit/175401d9f78758ac133c5abbf392b75df1ccc017 Author: Dan Wright Date: 2014-12-09 (Tue, 09 Dec 2014) Changed paths: M DBI.pm Log Message: --- Use multi_ for DBD::Multi per timbunce's request. Commit: 5533f1584468d6b5217c18071265cef1ba3312e5 https://github.com/perl5-dbi/dbi/commit/5533f1584468d6b5217c18071265cef1ba3312e5 Author: Jens Rehsack Date: 2014-12-09 (Tue, 09 Dec 2014) Changed paths: M DBI.pm Log Message: --- Add ad2_ prefix for clean room DBD::AnyData2 Commit: 6f25fd07640e7c09db9ad44a6627c5f5abaf1083 https://github.com/perl5-dbi/dbi/commit/6f25fd07640e7c09db9ad44a6627c5f5abaf1083 Author: Jens Rehsack Date: 2014-12-09 (Tue, 09 Dec 2014) Changed paths: M Changes Log Message: --- reflect prefix (multi_, ad2_) addition in Changes Compare: https://github.com/perl5-dbi/dbi/compare/eec58cba9d60...6f25fd07640e
Re: Bring AnyData / DBD::AnyData back to work with modern DBI
Am 13.11.2014 um 17:18 schrieb Jens Rehsack : > > Am 13.11.2014 um 16:47 schrieb Peter Rabbitson : > >> 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
Am 13.11.2014 um 16:47 schrieb Peter Rabbitson : > 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
Am 13.11.2014 um 15:08 schrieb Peter Rabbitson : > 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 : >> >>> 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
Am 13.11.2014 um 14:37 schrieb Tim Bunce : > 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 : >> >>> 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
Am 12.11.2014 um 16:14 schrieb Tim Bunce : > 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
Bring AnyData / DBD::AnyData back to work with modern DBI
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
[perl5-dbi/dbi] 93426f: add multi_ prefix for DBD::Multi as negotiated
Branch: refs/heads/multi_prefix-for-dbd-multi Home: https://github.com/perl5-dbi/dbi Commit: 93426f2d931bee132741afc2d8f1bdde6d2dffae https://github.com/perl5-dbi/dbi/commit/93426f2d931bee132741afc2d8f1bdde6d2dffae Author: Jens Rehsack Date: 2014-11-10 (Mon, 10 Nov 2014) Changed paths: M DBI.pm Log Message: --- add multi_ prefix for DBD::Multi as negotiated as negotiated in RT#93204 this add's a multi_ prefix for Dan's DBD::Multi. Thanks for mje@ reminding us.
Re: [perl5-dbi/dbi] 52be1b: Changed $sth->{TYPE} to be NUMERIC in DBD::File
Am 09.11.2014 um 13:21 schrieb H.Merijn Brand - Tux :
> Branch: refs/heads/dbd-file-TYPE
> Home: https://github.com/perl5-dbi/dbi
> Commit: 52be1b36c0b820fb905e6bd68e36ef472c01739a
>
> https://github.com/perl5-dbi/dbi/commit/52be1b36c0b820fb905e6bd68e36ef472c01739a
> Author: H.Merijn Brand - Tux
> Date: 2014-11-09 (Sun, 09 Nov 2014)
>
> Changed paths:
>M Changes
>M lib/DBD/File.pm
>M t/49dbd_file.t
>
> Log Message:
> ---
> Changed $sth->{TYPE} to be NUMERIC in DBD::File
While I always tried to delegate work on type_info to Merijn and Martin
(succeeded again ^^), the intension and the result are looking absolutely sane
to me.
Best regards and thanks Merijn
--
Jens Rehsack
rehs...@gmail.com
Re: AnyData / DBD::AnyData
Am 08.10.2014 um 15:51 schrieb H.Merijn Brand : > On Wed, 08 Oct 2014 21:05:55 +1000, Sven Dowideit > wrote: > >> Mmmm, to reply to all... >> >> Yes please - I currently work for Docker Inc, so barely have time to >> breath, let alone work on Perl things :) > > Hi Sven, I copied your github repo over to the dbi group and invited > you as a development AnyData team member. That implies that if you > agree, the DBI team now is the owner of the repo. You should accept the > invite, check the new clone, check that you can still push, alter your > meta-info and remove your current github repo. > > On CPAN, you are still the owner, and you'd be responsible for doing > the releases. Managing possible co-workers is not done on github. Sorry to straddling here ;) I'm owner on CPAN :P @Sven - I'd like to see more contributions when you find some tuits, don't know why the work for Docker Inc. nearly doesn't give you time to breath :( @Tux: I don't know what you have cloned - but seems to me you catched the wrong repository (https://github.com/SvenDowideit/Data-Foswiki instead of AnyData?) When you want to redo - you can clone https://github.com/SvenDowideit/DBD-AnyData, too - Sven took the relevant changes from CPAN and the few intermediate commits from backpan / svn aren't that important (IMHO). Cheers -- Jens Rehsack rehs...@gmail.com
AnyData / DBD::AnyData
Hi Sven, it seems I found a tuit wrt. AnyData & DBD::AnyData. I've seen your (released) work from Dec 2012 and ask kindly whether it's ok for you to move both modules, AnyData and DBD::AnyData to perl5-dbi repository and start migration of DataSources concept of DBD::File. AFAIK you told me you don't have any time for it and you're happy with any progress - but I'd like to be sure. Cheers -- Jens Rehsack rehs...@gmail.com
Re: IRC / DBIT meeting / T::WV
Am 27.03.2014 um 15:28 schrieb Tim Bunce : > On Tue, Mar 25, 2014 at 03:59:09PM +0100, Jens Rehsack wrote: >> Hi, >> >> because of reasons I will stay offline from IRC for some time. >> >> I intend to continue promised work on DBI::Test and would like to start on >> T::WV with including T::WV::Utils and a developer utility to create an 1) Merge the sandbox/tim/Writevariants/Utils (I don’t remember where it hides, but I’m going to hunt and find it and then merge to T::WV) *) include the Donald Knuth based variants adder from DBI::T::Conf variant (is for real a combination, because variant is order dependent and combination is not) and permutation >> inc/Bundle for T::WV. 2) Something which makes it easy to bundle T::WV (and Data::Tumbler) in one file in inc/ called from MF.PL which first try to load bundled version or higher from @INC and if not eval bundled one. >> Any objections? > > I'm not sure what you mean above Jens. I promise you’re not alone :D > Could you spell it out in (lots) more detail? Does that help confusing you? :) Cheers -- Jens Rehsack rehs...@gmail.com
Re: IRC / DBIT meeting / T::WV
Am 25.03.2014 um 15:59 schrieb Jens Rehsack : > Hi, > > because of reasons I will stay offline from IRC for some time. > > I intend to continue promised work on DBI::Test and would like to start on > T::WV with including T::WV::Utils and a developer utility to create an > inc/Bundle for T::WV. > > Any objections? I tend when there’re no objections until weekend I take for a „go ahead“ :) Cheers -- Jens Rehsack rehs...@gmail.com
IRC / DBIT meeting / T::WV
Hi, because of reasons I will stay offline from IRC for some time. I intend to continue promised work on DBI::Test and would like to start on T::WV with including T::WV::Utils and a developer utility to create an inc/Bundle for T::WV. Any objections? Cheers -- Jens Rehsack rehs...@gmail.com
[DBIT] Data::Tumbler -> L::MU
/wave
seems I finished the integration of D::T into the test concept of
List::MoreUtils (https://github.com/perl5-utils/List-MoreUtils).
This covers the generation of the tests from Makefile.PL, templating and minor
tweaks. It also covers the configure-requires and test-requires parts for
meta...
There’re two remaining issues:
1) t/00_compile.t should test all 3 (4) implementations separately (I have no
idea how to mix that with the current tests ...)
2) I have bad luck with „local $^W = 0;“ - part {} spies out warnings :(
But overall for test generation (not plugin management neither TestCase
management nor Fixtures nor ...) we’re on the right way.
As far as I understood, this was the first goal.
/me is excited about tomorrows DBIT weekly discussion.
Cheers
--
Jens Rehsack
rehs...@gmail.com
[perl5-dbi/dbi] 50d53f: add warning on unregistered driver (RT#93204)
Branch: refs/heads/master Home: https://github.com/perl5-dbi/dbi Commit: 50d53fbfdbb903bdd50e748376b3b62346d0afe2 https://github.com/perl5-dbi/dbi/commit/50d53fbfdbb903bdd50e748376b3b62346d0afe2 Author: Jens Rehsack Date: 2014-02-26 (Wed, 26 Feb 2014) Changed paths: M lib/DBI/DBD/SqlEngine.pm Log Message: --- add warning on unregistered driver (RT#93204)
[perl5-dbi/DBI-Test] 703732: add some concerns
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: 703732c75ace8531c0bfff403f5f98098777928a https://github.com/perl5-dbi/DBI-Test/commit/703732c75ace8531c0bfff403f5f98098777928a Author: Jens Rehsack Date: 2014-02-25 (Tue, 25 Feb 2014) Changed paths: M sandbox/tim/tumbler.pl Log Message: --- add some concerns
[perl5-dbi/dbi] 94c112: add class for driver without prefix warning
Branch: refs/heads/master Home: https://github.com/perl5-dbi/dbi Commit: 94c1125e5c9234eaee43548dddbd83f7d8ef7dbd https://github.com/perl5-dbi/dbi/commit/94c1125e5c9234eaee43548dddbd83f7d8ef7dbd Author: Jens Rehsack Date: 2014-02-26 (Wed, 26 Feb 2014) Changed paths: M lib/DBI/DBD/SqlEngine.pm M lib/DBI/DBD/SqlEngine/HowTo.pod Log Message: --- add class for driver without prefix warning + some POD clarifying that Commit: 2926ade0d15dd0c7175e4bf62ee1372cf9b136c8 https://github.com/perl5-dbi/dbi/commit/2926ade0d15dd0c7175e4bf62ee1372cf9b136c8 Author: Jens Rehsack Date: 2014-02-26 (Wed, 26 Feb 2014) Changed paths: M DBI.pm Log Message: --- add IRC resource Commit: dd33f52112fbfb957ab8f5e99fb8c250aa57ba8b https://github.com/perl5-dbi/dbi/commit/dd33f52112fbfb957ab8f5e99fb8c250aa57ba8b Author: Jens Rehsack Date: 2014-02-26 (Wed, 26 Feb 2014) Changed paths: M Changes Log Message: --- add note for fixing RT#93204 Compare: https://github.com/perl5-dbi/dbi/compare/50d53fbfdbb9...dd33f52112fb
Re: DBIT prototype - feedback wanted
Am 18.02.2014 um 13:56 schrieb Tim Bunce : > On Tue, Feb 18, 2014 at 09:35:20AM +0100, Jens Rehsack wrote: >> Am 18.02.2014 um 00:37 schrieb Tim Bunce : >> >>> Any feedback? >>> Any feedback at all? >> >> Also resend? Or do you mean from any other player? > > Other players, and also anything you might want to say about other > aspects of the prototype beyond the tumbler. Oh - I gave, but not in that detailed level I look tumbler & co, for reasons. First I (always) rephrase: every time I recognize what you, Tux, mje, ... are talking about, I realize how less I know about DBI. Please take my comments from that perspective (they all might pebcak ^^) 1) we had the redesign approach to reach a separate of concerns => we reached that with Data::Tumbler (at architect level) for variant+ management => the model how fixtures, DSN’s etc. are managed still confuse me (probably because the concerns are not such separated as I would have expected => maybe expectations must be updated) 2) + still today I didn’t understand the fixtures ribasushi has in mind with before creating ssh tunnels etc. and how we can built it using the available modules + I remember some concerns mje had regarding creating test databases (seems to be covered by existing plugins - but I didn’t got the API description ...) => requirements analysis missing or incomplete (at least for me) 3) platform for doing tests (connect_ok, prepare_ok, ...) is reused or missing? 4) Bootstrapping (self-test, Test::Database fundamentals, S::S, ...)is done using some kind of DBI::Mock or do we find another approach? From my point of view, the plugins on top of Tumbler and Context are some kind of easy mode (even if they already help find issues). That’s why I want to try to find an approach for unifying Data::Tumbler API (I’m not satisfied with the latest proposals but can’t tell why: I need to play around) and want to concentrate to that (keep concerns low to avoid Data::Confuser v2). Cheers, -- Jens Rehsack rehs...@gmail.com
Re: DBIT prototype - feedback wanted
Am 18.02.2014 um 00:37 schrieb Tim Bunce : > Any feedback? > Any feedback at all? Also resend? Or do you mean from any other player? > Tim. > > On Sun, Feb 09, 2014 at 11:18:24PM +, Tim Bunce wrote: >> As you probably know, I've been hacking on a rough DBI::Test prototype >> for a while. My primary goal has been to discover and explore the issues. >> Trying to write only the minimum amount of code to do so. >> >> It's now at the stage where there's something basic working for >> all the key aspects... >> >>Test variant generation >>The interface between the generated test script and the input test module >>Integration with Test::Database >>Fixture provider abstraction >>Fixture abstraction, including auto-teardown on DESTROY >>Support for unique table names so parallel testing works >> >> Please take a moment to read this README file: >> >>https://github.com/perl5-dbi/DBI-Test/blob/master/sandbox/tim/README.pod >> >> Then, ideally, checkout the repo and play with it. >> >> Then, please, give me feedback! >> >> What's good? >> What's bad? >> What can be done better? >> What's missing? >> What's are the priorities now? >> >> Thanks! >> >> Tim. Cheers -- Jens Rehsack rehs...@gmail.com
Re: "private" copy of Tumbler/Context
Am 16.02.2014 um 16:29 schrieb Tim Bunce :
> On Sat, Feb 15, 2014 at 12:07:13PM +0100, Jens Rehsack wrote:
>> Hi Tim,
>>
>> I’d like to go one step further with Tumbler and Context.
>> For LMU (https://github.com/perl5-utils/List-MoreUtils) and MooX::Cmd
>> (https://github.com/Getty/p5-moox-cmd) I’d like to write the
>> distributed tests based on a bundled (inc/, not installed etc.) copy
>> of Tumbler & Co.
>>
>> I think, seeing how it behaves in the wild will provide more
>> information. Also it allows to prove how good it can be adapted
>> (MooX::Test analogous to DBIT, but arranges tests with Mo, Moo, Moops
>> and Moose - and maybe for some hard guys, with
>> Class::Tiny+Role::Tiny). For LMU I have to test the
>> all/any/none/notall with different tests for different implementations
>> - but have also to test xs/perl ($ENV{LMU_PP}) and all implementations
>> in one import etc. (read: several test plugins parallel with different
>> function names to call ...).
>>
>> What do you think?
>
> Sounds good.
>
> I've renamed Tumbler to Data::Tumbler and polished it up a little
> (and made corresponding changes to both our tumbler.pl files).
git push eaten by stormy weather?
> I'm still not very happy about the interface between Data::Tumbler and
> Context, i.e.:
>
>tumbler(
>\@remaining_providers,
>$consumer,
>[ @$path, $name ],
>$context->new($context, $variants{$name}),<=== this
>$payload,
>);
>
> Tumbler shouldn't be coupled to Context at all.
>
> I think that should be either this:
>
>[ @$path, $name ],
>[ $context, $variants{$name} ],
> or
>[ @$path, $name ],
>$code_ref->($context, $variants{$name}),
I still prefer entire OO API (I really like function objects as
C++ provides them, but I think expecting users overload their
classes will be a no-go ^^) - this is one thingie I want to play
with.
> The first means that $context wouldn't be an object any more (though
> individual settings would) so instead of calling methods on context,
> like $context->get_env_var($name) you'd call functions like
> get_env_var_in_context($context, $name);
Objects with an expected role being provided sounds more reasonable
to me. This would also allow to hide implementation details (on
both sides).
> The second option means passing in an extra code ref into tumbler().
> Either as an extra parameter which then has to be passed down through
> the recursion, or by making Data::Tumbler be a class that has the code
> ref as an attribute.
>
> I'm leaning more towards the second as being an object is likely to have
> extra benefits.
>
>
> Returning to your suggestion of shipping Tumbler and Context a build-time
> tools
> in another module. Yes, that's worth doing.
>
> Note that Tumbler and Context are not directly related to the test
> generation use-case. So I think it would be a good idea to create another
> module which is aimed directly at supporting test generation and which
> uses Tumbler and Context. That module would contain get_input_tests(),
> write_test_file(), plus a plugin mechanism (eg for dbd_dbm_settings_provider).
>
> I suggest you start by creating a prototype of that module in
> sandbox/tim/lib and use it in sandbox/jens/tumbler.pl. Once you've
> something working I'll hack on it and adopt it in my tumbler.pl.
>
> Sound ok?
I would start in the real life (but not doing releases) and see whether it
works as expected or not. I did a minor shot for MooX::Cmd related tests and
I think it can work in a limited environment (MX::Cmd, LMU are such) for
clinical trials ;)
Cheers
--
Jens Rehsack
rehs...@gmail.com
[perl5-dbi/DBI-Test] 1d194d: add options test case
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: 1d194d8702dbdda2c6953cf3bc1426d1fe8ec691 https://github.com/perl5-dbi/DBI-Test/commit/1d194d8702dbdda2c6953cf3bc1426d1fe8ec691 Author: Jens Rehsack Date: 2014-02-11 (Tue, 11 Feb 2014) Changed paths: A sandbox/jens/plug/MXCOT/Options.pm Log Message: --- add options test case Commit: 391f9d9251c8446d5a11ac5db5440d11dc3abe70 https://github.com/perl5-dbi/DBI-Test/commit/391f9d9251c8446d5a11ac5db5440d11dc3abe70 Author: Jens Rehsack Date: 2014-02-12 (Wed, 12 Feb 2014) Changed paths: M sandbox/tim/README.pod M sandbox/tim/lib/Context.pm M sandbox/tim/tumbler.pl Log Message: --- Merge branch 'master' of github.com:/perl5-dbi/DBI-Test Compare: https://github.com/perl5-dbi/DBI-Test/compare/ff6fb0499608...391f9d9251c8
[perl5-dbi/DBI-Test] bd5b6f: add some playground for separation of concerns
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: bd5b6f545051e3263f3f694c9a7bb3bb2c170eb8 https://github.com/perl5-dbi/DBI-Test/commit/bd5b6f545051e3263f3f694c9a7bb3bb2c170eb8 Author: Jens Rehsack Date: 2014-02-11 (Tue, 11 Feb 2014) Changed paths: A sandbox/jens/plug/MXCT/Simple.pm A sandbox/jens/tumbler.pl Log Message: --- add some playground for separation of concerns
Re: DBIT prototype - feedback wanted
Am 12.02.2014 um 10:39 schrieb Tim Bunce :
> On Wed, Feb 12, 2014 at 09:08:43AM +0100, Jens Rehsack wrote:
>> Hi all,
>>
>> because I’m a bit overloaded at the moment, please don’t misinterpret
>> following as general reject or blame or something like that.
>>
>> I waited with the answer until I had time to create an own sandbox and shoot
>> a bit around.
>> Seems now I have some bullet holes :D
>
> :)
>
>> Am 10.02.2014 um 00:18 schrieb Tim Bunce :
>>
>>> What's good?
>>> What's bad?
>>> What can be done better?
>>> What's missing?
>>> What's are the priorities now?
>>
>> First: I like the general approach of separating of concerns. That’ll allows
>> to reuse the idea of flexible environments.
>> I tried it for my recent problem child MooX::Cmd (and extend some tests to
>> MooX::Options cooperation).
>> In principle, the "MooX::Options cooperation“ test case should be installed
>> to be reused from Vincent when hacking on MX::O ...
>>
>> So far so good - see
>> https://github.com/perl5-dbi/DBI-Test/tree/master/sandbox/jens how I tried
>> to reach those (more or less) simple goals.
>
> I'll take a look later.
>
>> My current sense of the entire stuff is:
>>
>> 1) I now have a rough intention how all must have felt when seeing my first
>> approach
>> 2) There is one complexity exchanged for another one
>> ==> neither are good
>> 3) To much implicit code - for having a test framework, I would prefer
>> explicit code,
>> especially mix between coderefs (providers) and values (test
>> cases/templates).
>> ==> Maybe having a Class::Tiny based API would improve (lazy attributes
>> ftw ^^)
>
> I'm not sure what you mean here Jens. Perhaps an explicit example of
> what you're concerned about would help.
dbd_dbm_settings_provider modifies *{ $main->{templates} } - if all providers
do that way, we soon have spaghetti DBIT.
See how first shot of moox_cooperations fails on a similar approach (for
reasons!),
while trying to building the bridge to MooX::Options.
>> 4) Probably a sandbox issue: Test::Database requires DBI -> Chicken Egg
>> Problem
>
> I suspect Test::Database will get split into two parts. (All DBIT really
> needs at the moment is a module to read the Test::Database config file.)
/me nods
The DBIT::DSN::Providers were meant as the lower layer part (no DBI
requirement).
Also something like the DBI::Mock might help to decouple (provides only NullP
^^).
>> 5) Providers framework need also support for variations, combinations and
>> permutations - mixing gofer+pureperl works only for small lists (add S::S
>> vs. Nano,
>> Gofer vs. DBD::Multiplex vs. DBD::Proxy ... (we don’t want to test Gofer
>> via Multiplex,
>> do we?) ).
>
> Gofer, Multiplex and Proxy are all proxies. I don't see a need to test
> stacking multiple proxies on top of each other.
>
> Beyond that I'm not sure what your concern is here. I don't see any
> problem adding more combinations to the DBI providers. I plan to add
> threads soon, for example.
No problems, it’s just complicated to create the combinations by hand.
The API/Framework shall come with a solution for creating all combinations
and permutations (without repetition) for a given list of provider
representations
(I don’t know how to express it correctly - whiteboard and a lot of pen’s and
arms
would help ^^).
>> 6) I didn’t find the time to rewrite „write_test_file“ - but I think a nice
>> template
>> as hacked in
>> https://github.com/i-scream/libstatgrab/blob/master/tests/testlib/mk_run_tests.pl
>> would allow more flexibility.
>
> For DBIT I don't see any need to rewrite write_test_file. Is there a need?
I do not see why on one hand we have a very high abstraction (providers) and
on the other hand we simply print out „unmodifiable" order of lines.
Conceptual we should have an abstraction here, too. It appears inconsistent (to
me)
otherwise ...
> For any other use of Tumbler you can write a 'consumer' sub that fits your
> needs.
Which in that case means: deliver another template and other hash with
key/values.
Cheers
--
Jens Rehsack
rehs...@gmail.com
Re: DBIT prototype - feedback wanted
Hi all, because I’m a bit overloaded at the moment, please don’t misinterpret following as general reject or blame or something like that. I waited with the answer until I had time to create an own sandbox and shoot a bit around. Seems now I have some bullet holes :D Am 10.02.2014 um 00:18 schrieb Tim Bunce : > As you probably know, I've been hacking on a rough DBI::Test prototype > for a while. My primary goal has been to discover and explore the issues. > Trying to write only the minimum amount of code to do so. > > It's now at the stage where there's something basic working for > all the key aspects... > >Test variant generation >The interface between the generated test script and the input test module >Integration with Test::Database >Fixture provider abstraction >Fixture abstraction, including auto-teardown on DESTROY >Support for unique table names so parallel testing works > > Please take a moment to read this README file: > >https://github.com/perl5-dbi/DBI-Test/blob/master/sandbox/tim/README.pod > > Then, ideally, checkout the repo and play with it. > > Then, please, give me feedback! > > What's good? > What's bad? > What can be done better? > What's missing? > What's are the priorities now? First: I like the general approach of separating of concerns. That’ll allows to reuse the idea of flexible environments. I tried it for my recent problem child MooX::Cmd (and extend some tests to MooX::Options cooperation). In principle, the "MooX::Options cooperation“ test case should be installed to be reused from Vincent when hacking on MX::O ... So far so good - see https://github.com/perl5-dbi/DBI-Test/tree/master/sandbox/jens how I tried to reach those (more or less) simple goals. My current sense of the entire stuff is: 1) I now have a rough intention how all must have felt when seeing my first approach 2) There is one complexity exchanged for another one ==> neither are good 3) To much implicit code - for having a test framework, I would prefer explicit code, especially mix between coderefs (providers) and values (test cases/templates). ==> Maybe having a Class::Tiny based API would improve (lazy attributes ftw ^^) 4) Probably a sandbox issue: Test::Database requires DBI -> Chicken Egg Problem 5) Providers framework need also support for variations, combinations and permutations - mixing gofer+pureperl works only for small lists (add S::S vs. Nano, Gofer vs. DBD::Multiplex vs. DBD::Proxy ... (we don’t want to test Gofer via Multiplex, do we?) ). 6) I didn’t find the time to rewrite „write_test_file“ - but I think a nice template as hacked in https://github.com/i-scream/libstatgrab/blob/master/tests/testlib/mk_run_tests.pl would allow more flexibility. I hope that doesn’t clean up any existing motivation and I really recognize it as a playground. Cheers -- Jens Rehsack rehs...@gmail.com
[perl5-dbi/DBI-Test] 9f033d: add missing use of Carp
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: 9f033d519a92b24450e00a5946ecd3ff4984c872 https://github.com/perl5-dbi/DBI-Test/commit/9f033d519a92b24450e00a5946ecd3ff4984c872 Author: Jens Rehsack Date: 2014-02-10 (Mon, 10 Feb 2014) Changed paths: M sandbox/tim/tumbler.pl Log Message: --- add missing use of Carp Commit: 758c7678869cedf2812c5de7f2ecc6a47c93dcbe https://github.com/perl5-dbi/DBI-Test/commit/758c7678869cedf2812c5de7f2ecc6a47c93dcbe Author: Jens Rehsack Date: 2014-02-10 (Mon, 10 Feb 2014) Changed paths: M sandbox/tim/README.pod M sandbox/tim/tumbler.pl Log Message: --- Merge branch 'master' of github.com:/perl5-dbi/DBI-Test Compare: https://github.com/perl5-dbi/DBI-Test/compare/35f9a86361a1...758c7678869c
No DBI::Test Meeting for me tomorrow
Hi, I have some $work commitment tomorrow which prevents me from attending DBIT meeting. Since I haven’t learned anything about required golden examples this week, I expect my attendance would be block others anyway - so please go ahead and I'm looking forward to an interesting meeting log. Cheers -- Jens Rehsack pkgsrc, Perl5 rehs...@cpan.org cpanid: REHSACK
Re: Common DBI Driver Test Suite - Requirements - take 2
Am 29.09.2013 um 21:02 schrieb Tim Bunce :
> Here's an updated Requirements document, tweaked a little based on the
> feedback.
>
>
> Goals: ("how will we know if this project is or is not a success")
>
>G1. driver developers improve their compliance with the DBI API
>and so improve consistency and portability of code.
>This is what it's all about!
>
>G2. driver developers adopt DBIT as a free test suite with good
>coverage of the DBI API. This is the pay-back _for_ developers.
>
>G3. driver developers write and share reusable generic tests
>(they'll still need to write their own driver-specific tests).
>This is the pay-back _from_ developers.
>
>G4. end users aren't affected by DBIT evolution causing install failures
>i.e., DBIT runs as 'author testing', *at least for now*.
>This is our promise to end users not to ruin their day.
>
>G5. works with the widest range of DBI drivers, including non-SQL and
>proxy drivers. This is a promise to be inclusive and flexible.
>
>G6. enables testing with DBI::PurePerl for pure-perl drivers.
>This is a promise to support fatpackers and perl6 ;)
>
>G7. end users can find the level of DBI API compliance of a driver
>The test configuration, e.g., what tests to skip, will be data-driven
>rather than hard-coded logic, and the data will readable via some API.
>
>
> Scope: (the boundaries and deliverables of the project)
>
>S1. the DBIT will be a separate distribution.
>
>S3. the DBI won't have a mandatory dependency on DBIT,
>for now at least, driver developers are the priority.
>
>S4. DBIT is not meant to test the underlying database.
>If a driver implements a database itself then it'll
>need it's own tests to provide good coverage of that.
>Those tests could use the DBIT infrastructure.
>
I don’t find the mail regarding that, but I remembered that my primary
goal is testing the underlying database (I call it SQL::Statement ^^).
> Requirements:
>
>R1. be easy for driver developers to adopt,
>so existing drivers migrate to using it.
>
>R2. be easy for driver developers to extend/contribute to,
>so driver developers contribute to it.
>
>R3. work well with cpantesters,
>so we get good coverage (perhaps extend Test::Database)
>
>R4. use get_info as the basis for determining the capabilities
>of the driver and database. We'll extend get_info as needed.
>
>R5. allow tests to be run in parallel, e.g. unique table names.
>
>R6. provides tools that drivers can use/extend for themselves.
>I'm thinking specifically here of the creation of test files
>with combinations of env vars and other settings.
>E.g., test DBD::CSV with Text::CSV and Text::CSV_XS
>
>
> Tim.
>
--
Jens Rehsack
rehs...@gmail.com
DBI::Test architecture meeting - Task(s) for today
Hi there, I collected the last mail-threads we’re discussed on DBIT: * http://www.mail-archive.com/dbi-dev@perl.org/msg07287.html * http://www.mail-archive.com/dbi-dev@perl.org/msg07323.html * http://www.mail-archive.com/dbi-dev@perl.org/msg07324.html * http://www.mail-archive.com/dbi-dev@perl.org/msg07325.html * http://www.mail-archive.com/dbi-dev@perl.org/msg07337.html Based on them I’d like to reach today at least that we are all upset and informed about the state of already decided goals, requirements and scope. Cheers -- Jens Rehsack rehs...@gmail.com
Re: DBI::Test - what does "templating" mean
Am 14.01.2014 um 12:13 schrieb Tim Bunce : > On Tue, Jan 14, 2014 at 09:23:19AM +0100, Jens Rehsack wrote: >> Hi everyone, > > Hi Jens. Hi Tim, >> I noticed last Wednesday that there is a lot of confusion what I mean when >> asking for how do we templating in DBI::Test. > > While that's true, I don't think it's the root cause of confusion. > > I think what we really need to discuss are requirements (high-level > use-cases) and the overall structure of "the system“. I didn’t want to talk about the variables used (INIT vs. PRE). I wanted to talk about the way of glueing the components (eg. simple variable expansion from hash vs. real, even simple templating language) > Without people sharing a good understanding of that context it's > hard to have useful discusions about lower-level implementation details. My intension wasn’t to low-level, but it’s difficult to express when you do nothing more than moving bits all the day ;) >> Beside all sides belonging to that question, I only meant the composition of >> the resulting .t file. > > Why do we need "composition of the resulting .t file" with more > functionality than my trivial prototype tumbler.pl does? Because DBI::Test needs DSN (how ever, even if it’s integrated later) and knowledge about managing the test cases. This shouldn’t be done by the current state of tumbler (though separations of concerns idea). > I'm not saying that we don't - I'm just trying to point out that we all > need to be clear about what we're trying to achieve here. And I wanted to get that question answered last week - not the details of the templating. > Step back Jens and paint a bigger picture in enough detail that the need > for templating becomes clear. > > We need to discuss: > where test code comes from, We (more or less) agreed that test code comes from separate test cases, which allows to run the test code several times with different test setups (in DBI::Test case: DBI_PUREPERL, Gofer, Nano vs. S::S, …) - but for showed example of MooX::Cmd before Christmas several runs with Moose, Moo and Mo are wanted. So Tumbler suits the test variant management - but should it also manage test code or not? Design state was: not (we can update that - be should be clear than). > who writes tests, Depends - some are bundled (eg. with DBI::Test - Tumbler will also bundle basic stuff for self-test, DBI will bundle tests which may or may not used for DBD testing, S::S will contribute tests for DBD::DBM etc.), some will be contributed by CPAN. > what kind of scope an individual test file has, At least the scope of the test case. > how they're shipped and installed. Neither nor, they’re generated during build an not installed at all. Test cases can be installed or not - think of „inc/„ dir in distributions. > Should test code be shipped in .t files, .pl files, or .pm files? In pm files > What's the least amount of knowledge that test code needs to work? That had already been discussed and has nothing to do with basic decisions But for all those questions, we initiated the Wednesday session. I’m happy to discuss tasks which are required before we can step to composing test files. Cheers -- Jens Rehsack rehs...@gmail.com
DBI::Test - what does "templating" mean
Hi everyone,
sorry for late summary.
I noticed last Wednesday that there is a lot of confusion what I mean when
asking for how do we templating in DBI::Test.
Beside all sides belonging to that question, I only meant the composition of
the resulting .t file.
For explaining examples I use a templating syntax loosely based on TT2.
In my implementation, the *.t files look:
#![% PERL_BIN %]
[% INIT.join(„\n“) %]
use DBI::Mock;
use DBI::Test::DSN::Provider;
use [% TEST_CASE %];
my \$test_case_conf = DBI::Test::DSN::Provider->get_dsn_creds("% TEST_CASE %]",
[% DSN %]);
% TEST_CASE %]->run_test(\$test_case_conf);
[% CLEANUP.join(„\n“) %]
The tumbler example currently uses (more or less)
#![% PERL_BIN %]
[% PRE %]
[% IF TESTINFO.REQUIRE.defined(); %] require [% TESTINFO.REQUIRE; END %]
[% TESTINFO.CODE %]
[% POST %]
For tumbler it’s fine to ignore separations of concern (test case management
must not be part), but the sample needs it for showing some output.
Before doing next steps (integrating tumbler), test case management and
templating should be discussed.
Cheers
--
Jens Rehsack
rehs...@gmail.com
Re: RFI: Database URIs
Am 25.11.2013 um 20:42 schrieb David E. Wheeler :
> On Nov 25, 2013, at 11:08 AM, Jens Rehsack wrote:
>
>> Let’s go - shoot:
>>
>> # specify most possible flags via driver flags
>> $dbh = DBI->connect ("dbi:CSV:", undef, undef, {
>> f_schema => undef,
>> f_dir=> "data",
>> f_dir_search => [],
>> f_ext=> ".csv/r",
>> f_lock => 2,
>> f_encoding => "utf8",
>>
>> csv_eol => "\r\n",
>> csv_sep_char => ",",
>> csv_quote_char => '"',
>> csv_escape_char => '"',
>> csv_class=> "Text::CSV_XS",
>> csv_null => 1,
>> csv_tables => {
>> info => { f_file => "info.csv" }
>> },
>>
>> RaiseError => 1,
>> PrintError => 1,
>> FetchHashKeyName => "NAME_lc",
>> }) or die $DBI::errstr;
>>
>> And keep in mind, csv_tables can be more complex and there’re other
>> attributes like it eg. in DBD::AnyData.
>
> Well, how you would want to handle params would be up to you. No, they are
> not great for hashes, but do-able.
>
>
> db:csv?f_dir=data&f_dir_search=foo&f_dir_search=bar&f_ext=.csv/r&f_lock=2&f_encoding=utf8&csv_eol=%0D%0A&csv_sep_char=,&csv_quote_char=%22&csv_escape_char=%22&csv+class=Text::CSV_XS&csv_null=1&RaiseError=1&PrintError=1&FetchHashKeyName=NAME_lc&csv_tables=%7B%22info%22%3A%20%7B%22f_file%22%3A%22info_csv%22%7D%7D
Happy hacking, when you want type that on command line. DBD::CSV (and other
Pure-Perl drivers) is designed for flexibility and quick setup, not for
expensive configuration and long-term running.
> So yeah, one would need to do some sort of parsting of nested data (JSON in
> the csv_tables example here), though arrays work okay (e.g., f_dir_search).
>
> OTOH, can you specify all this stuff in a DSN parseable by parse_dsn(),
> either?
You can’t - this is a clear point in DBI::DBD::SqlEngine at the moment.
> But my point is not to replace the connect() API, but to create a standard of
> sorts for representing connection info in a URL, to make it easier to specify
> how to connect to things on the command-line. Yeah, if you want to do
> everything, it will require more work, but that would be up to the code that
> handles each driver, which is to say the URI subclass for a particular DBMS.
All I say to you: if you want DBI supporting that - keep in mind the
whole requirements. If you just want to do another DBI extension, with
limited coverage and usage - feel free.
> But this discussion orthogonal to my original questions, which were:
>
> * Should I use a hierarchical scheme like JDBC? I’m leaning heavily toward
> this now, just need a decent prefix, I'm thinking "dbms", e.g.,
> "dbms:csv:foo“.
You can’t - because there is no „foo“ database for DBD::CSV at the moment.
Conceptual issue. In current state of development, those pure-perl DBMS
simulating drivers have no persistent metadata as mysql and postgresql have.
> * Do I have the metadata wrong for any of the DBMSes I have so far added
> support for? Right now that’s just the ports they listen on by default:
>
> https://github.com/theory/uri-db/blob/master/t/db.t#L9
I think you miss my point - I don’t say that you’re wrong, I say you
lack a lot of requirements. When you don’t intend to support those
pure-perl drivers, you’re fine and please go ahead. When you intend
full DBI driver support, DBDI (https://github.com/timbunce/DBDI) could
enlighten you. Following that concept would allow you a migration to p6
one fine day ;)
Cheers
--
Jens Rehsack
rehs...@gmail.com
Re: RFI: Database URIs
Am 25.11.2013 um 18:00 schrieb David E. Wheeler :
> On Nov 25, 2013, at 3:50 AM, Jens Rehsack wrote:
>
>> DBI->connect($dsn, $user, $passwd, \%attr)
>>
>> 4th argument is wasted in your current proposal.
>
> Er, well, I failed to provide a complete set of examples. Here’s one from the
> PostgreSQL docs:
>
>
> postgresql://other@localhost/otherdb?connect_timeout=10&application_name=myapp
>
> All the attributes are provided by the GET query string.
Let’s go - shoot:
# specify most possible flags via driver flags
$dbh = DBI->connect ("dbi:CSV:", undef, undef, {
f_schema => undef,
f_dir=> "data",
f_dir_search => [],
f_ext=> ".csv/r",
f_lock => 2,
f_encoding => "utf8",
csv_eol => "\r\n",
csv_sep_char => ",",
csv_quote_char => '"',
csv_escape_char => '"',
csv_class=> "Text::CSV_XS",
csv_null => 1,
csv_tables => {
info => { f_file => "info.csv" }
},
RaiseError => 1,
PrintError => 1,
FetchHashKeyName => "NAME_lc",
}) or die $DBI::errstr;
And keep in mind, csv_tables can be more complex and there’re other
attributes like it eg. in DBD::AnyData.
Cheers
--
Jens Rehsack
rehs...@gmail.com
Re: RFI: Database URIs
Am 23.11.2013 um 02:13 schrieb David E. Wheeler : > DBI Folks & Gisle, > > I want to add support for specifying database connections as URIs to Sqitch, > my DB change management system. I started working on it today, following the > examples of JDBC and PostgreSQL. Before I release, though, I’d like a bit of > feedback on a couple of things. > > First, I'm using the database name as the scheme in the URL. Some examples: > >postgresql://user@localhost:5433/dbname >sqlite:///path/to/foo.db > > This is to make it easy to tell one DB from another. But I'm wondering if I > should follow the example of JDBC more closely, and prepend "db:" or > something to them. More like DBI DSNs, too. However, it would require a bit > more work, as URI.pm does not currently recognize multiple colon-delimited > strings as scheme names AFAICT. :-( With that simplified scheme, you will never be able to support any DBI::DBD::SqlEngine derived driver. While you can configure on postgresql, mysql, oracle etc. a lot in configuration files and special tables, you can’t for DBD::CSV or DBD::DBM. The complete DBI->connect($dsn, $user, $passwd, \%attr) 4th argument is wasted in your current proposal. A lot of simple arguments can be encoded in DSN, but more complex stuff would require some kind of serialization (eg. JSON). Hacking JSON on CLI is always a charm ;) Thinking of Gofer (or other proxies) can shoot you in a new kind of hell ;) > Next, I've added a bunch of URI subclasses for various database engines. I’m > not to familiar with some of them, so if you see any listed here where the > name (to be used in the scheme) and the default port is wrong, please let me > know: > > https://github.com/theory/uri-db/blob/master/t/db.t#L9 > > Thanks! > > David > > PS: Is this something the DBI might want to use? > Cheers -- Jens Rehsack rehs...@gmail.com
Re: AnyData open API
Am 15.11.2013 um 02:00 schrieb djg...@gmail.com: > On Nov 14, 2013, at 1:09 AM, Jens Rehsack wrote: >>> >>> I just started looking into AnyData since I didn’t like all the work I was >>> doing to use the template feature of unpack then while processing building >>> a SQLite in-memory/file DB. I am thinking DBD::AnyData would be better and >>> easier to maintain than what I have built >>> >>> I notice DBD::AnyData doesn’t work with DBI > 1.622. I am willing to help >>> but not sure where to start. I may try to build a proof of concept from an >>> older DBI to see if it will be any faster/easier to maintain that what I am >>> doing now. >> >> I would recommend 1st to join IRC - at irc.perl.org in #dbi channel. >> If this is an absolute no-go, maybe a Hangout on Google+ would work better? > > I didn’t know there was a #dbi channel! I thought #dbix-class was the only > dbi channel. I have joined I am d^_^b or dj_goku or johnny5. :D You must be somewhere completely different. I’ve looked for several days and don’t see you. But: I’m kind of blind from time to time - please feel free to highlight me ([Sno]) or probably (H. Merijn Brand) Tux or vanHoesel (Theo van Hoesel). The introductional topics they all know and they know how to contact me (in doubt). >> However - the first step should be to read the concept and api of >> DBI::DBD::SqlEngine::(Table|Data)Source. I would favor this API even for >> AnyData and it’s storage backends. > > Alright looking at this now. > >> Let’s together develop an API on-top of it for parsing, if necessary. > > Alright this sounds good. I have no idea where to even start, but I’ll try to > help/learn! Start should be lib/DBI/DBD/SqlEngine.pm - read the developer and howto docs first. >> When AnyData got rid of the internal Tie stuff, a reintegration of >> DBD::AnyData into DBD::File will be a smooth way. Cheers -- Jens Rehsack rehs...@gmail.com
Re: AnyData open API
Hi Jonathan, Am 08.11.2013 um 02:59 schrieb djg...@gmail.com: > I hope my reply comes across correctly. Depends on your intension ;) I’d say: yes. >> Hi Jens and Sven, >> >> I understand that AnyData needs a reset. What is consensus if direction? >> >> For my project I need to manage a big variety of source formats, so I'll be >> willing to participate in redesign or coding of AnyData if need be. >> Otherwise >> I'll have to dream up my own data format abstraction layer. >> >> There are generally four types of sources or formats in my environment >> >> Databases accessible through DBI >> Databases accessible through command line binaries >> Records based files, such as csv >> Table based files, such as /etc/hosts, json etc. >> >> Any lessons we can stage from Augeas and it's concept of lenses? Or just >> bridge >> between Augeas and DBI? >> > > I just started looking into AnyData since I didn’t like all the work I was > doing to use the template feature of unpack then while processing building a > SQLite in-memory/file DB. I am thinking DBD::AnyData would be better and > easier to maintain than what I have built > > I notice DBD::AnyData doesn’t work with DBI > 1.622. I am willing to help but > not sure where to start. I may try to build a proof of concept from an older > DBI to see if it will be any faster/easier to maintain that what I am doing > now. I would recommend 1st to join IRC - at irc.perl.org in #dbi channel. If this is an absolute no-go, maybe a Hangout on Google+ would work better? However - the first step should be to read the concept and api of DBI::DBD::SqlEngine::(Table|Data)Source. I would favor this API even for AnyData and it’s storage backends. Let’s together develop an API on-top of it for parsing, if necessary. When AnyData got rid of the internal Tie stuff, a reintegration of DBD::AnyData into DBD::File will be a smooth way. Cheers -- Jens Rehsack rehs...@gmail.com
Re: SQL::Statement::Embed example failing
Am 07.11.2013 um 14:04 schrieb Søren Døssing : > Hej Jens, Hi Søren, > Can I disturb you again. Since AnyData doesn't seem to be going anywhere, Well, joint with Sven and Theo and go on hacking. Of course you can count on me answering questions and guide you as good as I can. > I'm looking at writing own DBD drivers. Documentation say’s: don’t! - from my point of view, if AnyData and DBD::AnyData will do for you once fixed, don’t end like DBD::PO or DBD::SNMP - do the right thing and work on AnyData and DBD::AnyData. > I tried out the examples on > http://search.cpan.org/~rehsack/SQL-Statement-1.405/lib/SQL/Statement/Embed.pod > but they don't work. The DBD::Foo example gives the following error message: > > --- snip --- > wit:bin sauber$ perl -I../lib dbdfoo.pl > Use of uninitialized value $drv_prefix in concatenation (.) or string at > /opt/local/lib/perl5/site_perl/5.12.4/darwin-thread-multi-2level/DBI/DBD/SqlEngine.pm > line 434. > Use of uninitialized value $drv_prefix in concatenation (.) or string at > /opt/local/lib/perl5/site_perl/5.12.4/darwin-thread-multi-2level/DBI/DBD/SqlEngine.pm > line 435. > Use of uninitialized value $drv_prefix in concatenation (.) or string at > /opt/local/lib/perl5/site_perl/5.12.4/darwin-thread-multi-2level/DBI/DBD/SqlEngine.pm > line 449. > Use of uninitialized value $drv_prefix in concatenation (.) or string at > /opt/local/lib/perl5/site_perl/5.12.4/darwin-thread-multi-2level/DBI/DBD/SqlEngine.pm > line 479. > Use of uninitialized value $drv_prefix in concatenation (.) or string at > /opt/local/lib/perl5/site_perl/5.12.4/darwin-thread-multi-2level/DBI/DBD/SqlEngine.pm > line 479. > Use of uninitialized value $drv_prefix in concatenation (.) or string at > /opt/local/lib/perl5/site_perl/5.12.4/darwin-thread-multi-2level/DBI/DBD/SqlEngine.pm > line 479. > Use of uninitialized value $drv_prefix in concatenation (.) or string at > /opt/local/lib/perl5/site_perl/5.12.4/darwin-thread-multi-2level/DBD/File.pm > line 196. > Use of uninitialized value $drv_prefix in concatenation (.) or string at > /opt/local/lib/perl5/site_perl/5.12.4/darwin-thread-multi-2level/DBI/DBD/SqlEngine.pm > line 612. > Use of uninitialized value $drv_prefix in concatenation (.) or string at > /opt/local/lib/perl5/site_perl/5.12.4/darwin-thread-multi-2level/DBI/DBD/SqlEngine.pm > line 612. > DBD::Foo::st execute failed: > Execution ERROR: Table 'group_id' already exists.. > > at > /opt/local/lib/perl5/site_perl/5.12.4/darwin-thread-multi-2level/DBI/DBD/SqlEngine.pm > line 1239. > [for Statement "CREATE TABLE group_id (username CHAR,uid INT, gid INT)"] > at dbdfoo.pl line 17. > wit:bin sauber$ > --- snap --- > > I tried a variety of operating systems and perl versions and always get same > error message. > > Any chance you can lead me along the way? I recommend you check the http://search.cpan.org/dist/DBI/lib/DBI/DBD/SqlEngine/Developers.pod & Co documents. SQL::Statement has only a rough example which should demonstrate howto use S::S when you already know how to develop a DBD. Cheers -- Jens Rehsack rehs...@gmail.com
Week 44 - summary of DBIT meeting
Hi all, before next DBIT weekly irc summit happens, here’s promised mail of last one: Tim finished the tumbler.pl and that allows to update DBI::Test::Conf using and (however named) DBI::Test::Tumbler. The plan is to hack such a thing in very near future. For that small next step, the assumption is made of fixtures being Roles of test cases. We know that we have to think about test case templates, fixtures, DSN’s and so on - and we need to do the same discussion we had for config providers for all the other things, too. Maybe tomorrow at 10:30 Europe/Berlin (9:30 Europe/Dublin) can be some more people want to say something about that. Cheers -- Jens Rehsack pkgsrc, Perl5 rehs...@cpan.org cpanid: REHSACK
Re: AnyData open API
Am 12.10.2013 um 00:49 schrieb Sven Dowideit : > Heya Søren and Jens, /wave > It depends :) > > The API for the AnyData module is relatively well documented in the code - I > was able to use it pretty quickly. on the other hand DBI::AnyData is broken > (and this is the issue Jens is talking about) I also talk about your later statement "large parts of AnyData mismatched or redundant" - especially the redundant part. From architectural point of view, AnyData needs a redesign to modularize storage backends, as DBI::DBD::SqlEngine suggests. > I started to look into this (a year or more ago?) but I had to step back, and > havn't found either the time, energy or idea on what to do about it. > > fundamentally, DBI::AnyData was once a very light wrapper around AnyData, but > DBI has changed in ways that makes large parts of AnyData mismatched or > redundant. > > So - if you want a fast to code Tied hash interface into your data, AnyData > is pretty nice. But if you really want DBI/SQL access to it, er, then DBI has > more modern modules to help you > > (wrt moving the git repo - do you really want the AnyData code in there, or > just DBI::AnyData?) I want both there, because it more or less belongs together. DBD::AnyData makes no sense without AnyData. I always thought I moved DBD::AnyData from svn.perl.org, but I didn't. I cannot promise for this week - but I try to move asap. Shall I simply fork you're AnyData repo to perl5-dbi and you do a new clone from there? > Sven > > > On 12/10/13 00:10, Jens Rehsack wrote: >> Am 07.10.2013 um 02:37 schrieb Søren Døssing : >> >>> Where is open API for AnyData documented? >>> >>> In particular I'm interested in how to write a module that does bulk >>> table import/export instead read/write individual records. >>> >>> /etc/hosts file is an example; multiple host names map to a single ip, >>> so adding a record is no longer a matter of a simple append. >> Hi Søren, >> >> I'm sorry to respond such late. >> >> To be true - even if I would point you to some documentation, it wouldn't >> satisfy you're needs neither it would be fair since I plan a more or less >> hard refactoring. >> >> A few month ago we integrated an API into DBI::DBD::SqlEngine for such >> kind of interaction, especially for DBD::File related DBD's as DBD::AnyData. >> >> Because of $work, family, etc. we stuck a bit but today I officially set >> the NEEDHELP flag on PAUSE which says: I want help to move AnyData and >> DBD::AD to the improved basic of DBI::DBD::SqlEngine and start over >> with AnyData. >> >> I know Sven has created a GitHub repository. It should be moved to perl5-dbi >> which would allow anyone on DBI-Team to grant support. Cheers -- Jens Rehsack pkgsrc, Perl5 rehs...@cpan.org
Re: AnyData open API
Am 07.10.2013 um 02:37 schrieb Søren Døssing : > Where is open API for AnyData documented? > > In particular I'm interested in how to write a module that does bulk > table import/export instead read/write individual records. > > /etc/hosts file is an example; multiple host names map to a single ip, > so adding a record is no longer a matter of a simple append. Hi Søren, I'm sorry to respond such late. To be true - even if I would point you to some documentation, it wouldn't satisfy you're needs neither it would be fair since I plan a more or less hard refactoring. A few month ago we integrated an API into DBI::DBD::SqlEngine for such kind of interaction, especially for DBD::File related DBD's as DBD::AnyData. Because of $work, family, etc. we stuck a bit but today I officially set the NEEDHELP flag on PAUSE which says: I want help to move AnyData and DBD::AD to the improved basic of DBI::DBD::SqlEngine and start over with AnyData. I know Sven has created a GitHub repository. It should be moved to perl5-dbi which would allow anyone on DBI-Team to grant support. Cheers -- Jens Rehsack pkgsrc, Perl5 rehs...@cpan.org
Re: Proposal: Test::MakeVariantTestFiles
Am 30.09.2013 um 20:03 schrieb Tim Bunce :
> On Mon, Sep 30, 2013 at 08:52:04AM +0200, Jens Rehsack wrote:
>>
>> Am 29.09.2013 um 21:26 schrieb Tim Bunce :
>>
>>> The DBI adopted an approach towards testing 'variants' by creating extra
>>> test files that act as wrappers around existing test files.
>>>
>>> The wrappers modify the process in some way, such as setting environment
>>> variables, before executing the original test file.
>>>
>>> It works well, and the DBIT has adopted the same approach.
>>>
>>> I think the approach is good and more widely applicable than just the DBI.
>>>
>>> I'd like to propose that we factor it out into a separate distribution.
>>>
>>> Thoughts?
>>
>>
>> I had the same idea - even several separate distributions, but I rejected
>> myself there for following reasons:
>>
>> 1) The variants of the driver result in an n choose k combination
>> 2) The driver attributes (eg. list of dbm backends, list of mldbm
>> serializers)
>> result in a cross product of those vectors.
>>
>> When making separate distributions, 1st approach would be to create a really
>> generic combinatorics distribution. There are some, but all currently have
>> drawbacks. This distribution would likely develop an own life (combinatoric
>> problems tend to become complex and require lot of performance speed ups).
>>
>> Based on that Math::Fast::Combi (*gg*) Test::MakeVariantTesTFiles would
>> require exactly to know what shall be done where.
>
> I think it just requires a callback to prune combinations that aren't wanted.
That callback can be complicated and the decision can be made at several points:
* configuration definition
* test case
* datasource configurator (DSN::Provider, Test::Database)
The routing of those decision callbacks could be somewhat complicated but
with some effort reasonable.
>> I think - from the current point of view, this would result in an over
>> complex API. Maybe sourcing out the combinatoric algorithms would clean
>> up the code a bit and later when we know better we can additionally create
>> a distributions for computing variants (combinations, variations,
>> permutations,
>> cross products, …) and based on that ?
>
> I think a clean simple API could be designed. Keeping the test rewriting
> logic separate simplifies the rest of DBIT. It's a Separation Of Concerns.
>
> Here's a rough suggestion for an API:
>
>write_variants(
># required:
>test_files => [
>'t/foo.t', ...
>],
>variants => {
>wibble => { ... },
>wobble => { ... },
>},
># optional:
>filter => sub {
>my ($test_file, $variant_set) = @_;
>delete $variant_set->{wibble} if ...;
>return [ %$variant_set ]
>}
>);
>
> The write_variants sub would call the filter callback for every combination
> of variants (in this example: wibble alone, wobble alone, wibble + wobble).
And for "none" ;)
> The filter can return zero or more array refs where each array contains
> the variants to be applied, in order. Returning nothing means don't
> create variants for that test. Returning multiple items makes it easy
> for the filter to generate extra permutations if appropriate for some tests.
>
> What's missing?
Short answer: More levels and driver tunable settings. I give you a longer
example call (of the currently supported and implemented variants - beside
the filter callback - DBI::Test::Conf can populate):
write_variants(
# required:
test_cases => {
foo => '@BEGIN@
do "t/foo.t"
@END@',
bar => '@BEGIN@
do "t/bar.t"
@END@',
},
variants => {
dbi => {
pureperl => {
name => "DBI::PurePerl",
category => "dbi",
cat_abbrev => "z",
abbrev => "p",
init_stub=> [
'$ENV{DBI_PUREPERL} = 2', ],
cleanup_stub => ['delete
$ENV{DBI_PUREPERL};'],
},
},
dialect => {
ans
Requirements DSN::Provider / Test::Database
Hi,
the discussion whether to re-use Test::Database or develop a probably
common ancestor should base on goals, scope and requirements as it
seems to be reasonable for DBIT …
Goals: ("how will we know if this project is or is not a success")
G1: Out of the box any DBIT Test Case can be run against any
(suitable) driver tunable configuration.
G2: Supports beside DBI/DBD tests also applications and DBIC
Scope: (the boundaries and deliverables of the project)
S1: CREATE TABLE necessary?
S2: DBI::Mock ?
Requirements:
R1: Must not require DBI (for being useful for SQL::Statement)
R2: Must be able to distinguish between simple tests (where
driver defaults are fine) and exhaustive tests (all tunable's
shall be tested)
R3: Must be able to use environment settings for detailed
connection target information
R4: Must be able to rely on configuration for non-DBI/DBD test
cases (Applications, DBIC, …)
R4a: Must be able to determine / filter / reduce configuration
upon tests are running
==> for DBD::xyz (don't deliver DBD::abc DSN's)
==> for applications (deliver the DSN's for the DBD's
the application is using)
==> for DBIC and alike (deliver all configured DSN's)
Best regards
--
Jens Rehsack
rehs...@gmail.com
Weekly DBIT IRC meeting - Wed. 9:00 CET
Hi all, on last niederrhein.pm Meeting, Peter Rabbitson (ribasushi), H.Merijn Brand (Tux) and me (Jens Rehsack - Sno) agreed on a weekly meeting in IRC regarding DBIT. All topics can be covered and I announce it loudly to attract more attendees. Best regards -- Jens Rehsack pkgsrc, Perl5 rehs...@cpan.org
Re: Using Test::Database with DBIT
Am 30.09.2013 um 22:44 schrieb Tim Bunce : > On Mon, Sep 30, 2013 at 08:36:33AM +0200, Jens Rehsack wrote: >> Am 29.09.2013 um 21:20 schrieb Tim Bunce : >> >>> I'd appreciate a summary of how DBI::Test::DSN::Provider differs from >>> Test::Database and/or how they might work together. >> >> I discussed with BooK before hacking DSN::Providers for DBIT. >> >> The primary consensus was: Test::Database is made for testing applications >> against databases used by the application. >> >> The approach of the DBIT::DSN::Providers was to provide driver DSN's and >> attribute variants for the drivers to test. > > I'm not convinced that Test::Database couldn't be extended to suit. > > I'd appreciate specific details of relevant limitations of Test::Database. If you want I can dig for the IRC logs. BooK (the author) convinced me that it's not usable and neither intended. It could be possible to separate a base API from several implementation like did in Log::Any. We should ask Philippe whether he would support that. Cheers -- Jens Rehsack pkgsrc, Perl5 rehs...@cpan.org
Re: Proposal: Test::MakeVariantTestFiles
Am 29.09.2013 um 21:26 schrieb Tim Bunce : > The DBI adopted an approach towards testing 'variants' by creating extra > test files that act as wrappers around existing test files. > > The wrappers modify the process in some way, such as setting environment > variables, before executing the original test file. > > It works well, and the DBIT has adopted the same approach. > > I think the approach is good and more widely applicable than just the DBI. > > I'd like to propose that we factor it out into a separate distribution. > > Thoughts? I had the same idea - even several separate distributions, but I rejected myself there for following reasons: 1) The variants of the driver result in an n choose k combination 2) The driver attributes (eg. list of dbm backends, list of mldbm serializers) result in a cross product of those vectors. When making separate distributions, 1st approach would be to create a really generic combinatorics distribution. There are some, but all currently have drawbacks. This distribution would likely develop an own life (combinatoric problems tend to become complex and require lot of performance speed ups). Based on that Math::Fast::Combi (*gg*) Test::MakeVariantTesTFiles would require exactly to know what shall be done where. I think - from the current point of view, this would result in an over complex API. Maybe sourcing out the combinatoric algorithms would clean up the code a bit and later when we know better we can additionally create a distributions for computing variants (combinations, variations, permutations, cross products, …) and based on that ? Cheers -- Jens Rehsack pkgsrc, Perl5 rehs...@cpan.org
Re: Using Test::Database with DBIT
Am 29.09.2013 um 21:20 schrieb Tim Bunce : > Has anyone got any experience with recent version of Test::Database? > > I'm wondering how it would integrate with DBIT and what extensions might > be needed. > > When a driver uses DBIT for tests it would request test database handles > that match the driver name. > > When DBIT itself is being tested, either via travis > (http://about.travis-ci.org/docs/user/database-setup/) or cpantesters, > we'll want to run against all the configured and available databases. > > I'd appreciate a summary of how DBI::Test::DSN::Provider differs from > Test::Database and/or how they might work together. I discussed with BooK before hacking DSN::Providers for DBIT. The primary consensus was: Test::Database is made for testing applications against databases used by the application. The approach of the DBIT::DSN::Providers was to provide driver DSN's and attribute variants for the drivers to test. Cheers -- Jens Rehsack rehs...@gmail.com
Re: Common DBI Driver Test Suite - Requirements
Am 27.09.2013 um 00:03 schrieb Tim Bunce : > On Wed, Sep 25, 2013 at 08:36:22PM +0200, Jens Rehsack wrote: > >> For me, a G10 is interesting (handling SQL::Statement as a DBD) >> >> G10: Provide tools/infrastructure to combines several test cases in >> particular order into tests to allow workflows being tested >> and stress tests by looping can be performed. > > Also here. I'm not quite sure what problem this is trying to address. This is more or less an idea I had during test development. For a lot of tests, we write some sequences of statements to finally prove one or a few things working fine (at least for DBD::CSV, DBD::DBM and a lot of SQL::Statement tests - but IIRC, this is true for SQLite, too). So for testing whether UPDATE/DELETE works, we create some tables, do some inserts and after that, modify them. For SELECT testing, same. For ChopBlank testing (via select, of course), similar. For JOIN testing, more tables - but finally the same. This goes on … (different edge cases to test, but finally all the same). For SQL::Statement I added a performance check )for being run through the profilers we have) which is assembled from one or more of the above tests. But by hand. If there is a design of combining test cases to a sequence of tests (eg. create tables -> fill data -> select -> update -> delete -> drop), it could help simplifying test cases and allow put loops around sequences to redo some test sequence for 100 times for profiling. The design finally choosen for this goal might be a composite for test cases - but the test case design shall allow doing that. Cheers -- Jens Rehsack rehs...@gmail.com
[perl5-dbi/DBI-Test] 16a394: make Error and Warn test ready for deplyoment
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: 16a394ca1f637dc901c94dcad7c06dbe692e3c3f https://github.com/perl5-dbi/DBI-Test/commit/16a394ca1f637dc901c94dcad7c06dbe692e3c3f Author: Jens Rehsack Date: 2013-09-25 (Wed, 25 Sep 2013) Changed paths: A lib/DBI/Test/Case/attributes/Error.pm M lib/DBI/Test/Case/attributes/Warn.pm M lib/DBI/Test/List.pm Log Message: --- make Error and Warn test ready for deplyoment
[perl5-dbi/DBI-Test] 532194: remove test cases which won't work standalone
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: 53219459c4405e606c8273549d17c937ea07c79a https://github.com/perl5-dbi/DBI-Test/commit/53219459c4405e606c8273549d17c937ea07c79a Author: Jens Rehsack Date: 2013-09-25 (Wed, 25 Sep 2013) Changed paths: R lib/DBI/Test/Case/basic/bind_columns.pm R lib/DBI/Test/Case/basic/do.pm R lib/DBI/Test/Case/basic/execute.pm R lib/DBI/Test/Case/basic/prepare.pm R lib/DBI/Test/Case/basic/type_info.pm Log Message: --- remove test cases which won't work standalone * To prepare/execute (do), bind_columns or fetch type_info some kind of engine/backend is required - skip those stuff Commit: 1da1392e2dbed0e895999418c6f67b8398827a43 https://github.com/perl5-dbi/DBI-Test/commit/1da1392e2dbed0e895999418c6f67b8398827a43 Author: Jens Rehsack Date: 2013-09-25 (Wed, 25 Sep 2013) Changed paths: R xt/00_pod.t R xt/01_pod.t R xt/10_perlversion.t A xt/perlversion.t A xt/pod-coverage.t A xt/pod.t Log Message: --- bring xt/ into the form I have any other of mine Commit: f27e60e9c0eea1db55e1cf7e0a4e1847853b1291 https://github.com/perl5-dbi/DBI-Test/commit/f27e60e9c0eea1db55e1cf7e0a4e1847853b1291 Author: Jens Rehsack Date: 2013-09-25 (Wed, 25 Sep 2013) Changed paths: A xt/changes.t A xt/manifest.t M xt/perlversion.t A xt/pod-cm.t M xt/pod-coverage.t M xt/pod.t Log Message: --- decision was, making author tests mandatory Commit: ecd8dff1e7729ec280eb6c1f49119f854c856795 https://github.com/perl5-dbi/DBI-Test/commit/ecd8dff1e7729ec280eb6c1f49119f854c856795 Author: Jens Rehsack Date: 2013-09-25 (Wed, 25 Sep 2013) Changed paths: M ChangeLog M xt/changes.t M xt/perlversion.t M xt/pod-cm.t Log Message: --- bring up author tests ... Commit: 2d695a5835332c59fc80cd00f8be2d7184ef06d5 https://github.com/perl5-dbi/DBI-Test/commit/2d695a5835332c59fc80cd00f8be2d7184ef06d5 Author: Jens Rehsack Date: 2013-09-25 (Wed, 25 Sep 2013) Changed paths: M lib/DBI/Mock.pm M lib/DBI/Test.pm M lib/DBI/Test/Case.pm M lib/DBI/Test/Conf.pm M lib/DBI/Test/List.pm Log Message: --- improve documentation of the base classes Compare: https://github.com/perl5-dbi/DBI-Test/compare/a2fd4eac5a54...2d695a583533
[perl5-dbi/DBI-Test] 8141fa: hopefully useful description of GOALs and DESIGN
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: 8141fab822a185235311c924b7b5f567e2fd52dd https://github.com/perl5-dbi/DBI-Test/commit/8141fab822a185235311c924b7b5f567e2fd52dd Author: Jens Rehsack Date: 2013-09-25 (Wed, 25 Sep 2013) Changed paths: A misc/DESIGN.md A misc/GOAL.md Log Message: --- hopefully useful description of GOALs and DESIGN ... at the current state
[perl5-dbi/DBI-Test] 7462e3: make Error and Warn test ready for deplyoment
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: 7462e3f91c2ccfdece763070fac155913e3ab27a https://github.com/perl5-dbi/DBI-Test/commit/7462e3f91c2ccfdece763070fac155913e3ab27a Author: Jens Rehsack Date: 2013-09-25 (Wed, 25 Sep 2013) Changed paths: A lib/DBI/Test/Case/attributes/Error.pm R lib/DBI/Test/Case/attributes/PrintError.pm M lib/DBI/Test/Case/attributes/Warn.pm M lib/DBI/Test/List.pm Log Message: --- make Error and Warn test ready for deplyoment Commit: ac9557bf00ae1d10c575415aab025fcbdc358e44 https://github.com/perl5-dbi/DBI-Test/commit/ac9557bf00ae1d10c575415aab025fcbdc358e44 Author: Jens Rehsack Date: 2013-09-25 (Wed, 25 Sep 2013) Log Message: --- Merge branch 'master' of github.com:/perl5-dbi/DBI-Test Compare: https://github.com/perl5-dbi/DBI-Test/compare/16a394ca1f63...ac9557bf00ae
Re: Common DBI Driver Test Suite - Requirements
Am 25.09.2013 um 19:27 schrieb Tim Bunce : > On Wed, Sep 25, 2013 at 07:02:07PM +0200, H.Merijn Brand wrote: >> On Wed, 25 Sep 2013 17:28:04 +0100, Tim Bunce >> wrote: >> >>>G9. end users can find the level of DBI API compliance of a driver >>>i.e., by looking at the test configuration for the driver >>>to see what areas of functionality are configured to be skipped. >> >> I have a hard time parsing that. > > Drivers have various limitations, things they don't, or can't, support. > It would be unreasonable for them to fail DBIT for those reasons. > So there needs to be a way for those drivers to tell DBIT that > certain tests should be skipped. Riba put that into a R4: It should be possible to configure which test(case) should be run and which not. This should be possible in a manner which avoids asking cpantesters 100 y/n questions ^^ Maybe this belongs to that point (Riba should be able to explain better). For me, a G10 is interesting (handling SQL::Statement as a DBD) G10: Provide tools/infrastructure to combines several test cases in particular order into tests to allow workflows being tested and stress tests by looping can be performed. > And not just drivers. Things like proxies will need to influence > what's expected to work. This is a key area. > > What G9 is trying to express is that that information (which tests to > skip) is useful for end users, and probably applications as well. > So we should aim to design the system in a way that make that > information available in a useful way. > > Some of that might end up being handled by $dbh->get_info() but there's > bound to be some that isn't. > > >>>S4. DBIT is not meant to test the underlying database. >>>If a driver implements a database itself then it'll >>>need it's own tests to provide good coverage of that. >> >> DBIT will offer the interface to test the underlying database. What is >> important here, as DBIT will offer the possibility to test under >> different circumstances (like with SQL::Nano or under DBI::Proxy) >> without having to rewrite all tests over and over again. >> These test will reside in the test suite of the DBD, not in the test >> suite of DBIT > > Yes. Or, for drivers that want to share tests, those tests could live in > modules installed by a distro that the driver declares it's dependant on. I would prefer the "distributed separately" way. It doesn't have to be dozen of independent distributions, there could be a few thematically grouped ones. Like some for ANSI SQL, some for proxy specific ones (like spreading some requests to see how the scaling is?), …) Cheers -- Jens Rehsack pkgsrc, Perl5 rehs...@cpan.org
Re: Common DBI Driver Test Suite - Requirements
Am 25.09.2013 um 19:02 schrieb H.Merijn Brand : > On Wed, 25 Sep 2013 17:28:04 +0100, Tim Bunce > wrote: > >> Hi all. >> [...] > >>G8. Provide tools that drivers can use/extend for themselves. >>I'm thinking specifically here of the creation of test files >>with combinations of env vars and other settings. >>E.g., test DBD::CSV with Text::CSV and Text::CSV_XS > > As a goal, this is fine. For DBD::CSV, this falls under G7: It will use > Text::CSV_PP (from Text::CSV) under DBI::PurePerl and Text::CSV_XS > under DBI (XS) Don't discuss implementation details here. Keep this argument in mind and come back on that later. Then I tell you why I think you have a 3rd case and so need a G8 :D Cheers -- Jens Rehsack pkgsrc, Perl5 rehs...@cpan.org
[perl5-dbi/dbi] 98586f: Fix loading issue without DBI.so
Branch: refs/heads/dbi-test-conditional Home: https://github.com/perl5-dbi/dbi Commit: 98586fedb09129c4569dcc0f9cdd444384b144f2 https://github.com/perl5-dbi/dbi/commit/98586fedb09129c4569dcc0f9cdd444384b144f2 Author: Jens Rehsack Date: 2013-09-18 (Wed, 18 Sep 2013) Changed paths: M Makefile.PL Log Message: --- Fix loading issue without DBI.so
[perl5-dbi/DBI-Test] 849edd: remove special case handling where it shouldn't be
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: 849edd60ddc42779231ebb3fa6044733f1d05780 https://github.com/perl5-dbi/DBI-Test/commit/849edd60ddc42779231ebb3fa6044733f1d05780 Author: Jens Rehsack Date: 2013-09-18 (Wed, 18 Sep 2013) Changed paths: M lib/DBI/Test/Conf.pm Log Message: --- remove special case handling where it shouldn't be
[perl5-dbi/DBI-Test] fea06e: add initial version number (0.001)
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: fea06e8cda31cbebc8064099a41d4cd81c2a55de https://github.com/perl5-dbi/DBI-Test/commit/fea06e8cda31cbebc8064099a41d4cd81c2a55de Author: Jens Rehsack Date: 2013-09-18 (Wed, 18 Sep 2013) Changed paths: M lib/DBI/Mock.pm M lib/DBI/Test/Case.pm M lib/DBI/Test/Case/attributes/PrintError.pm M lib/DBI/Test/Case/attributes/Warn.pm M lib/DBI/Test/Case/basic/bind_columns.pm M lib/DBI/Test/Case/basic/connect.pm M lib/DBI/Test/Case/basic/disconnect.pm M lib/DBI/Test/Case/basic/do.pm M lib/DBI/Test/Case/basic/execute.pm M lib/DBI/Test/Case/basic/prepare.pm M lib/DBI/Test/Case/basic/type_info.pm M lib/DBI/Test/Conf.pm M lib/DBI/Test/DSN/Provider.pm M lib/DBI/Test/DSN/Provider/Base.pm M lib/DBI/Test/DSN/Provider/Config.pm M lib/DBI/Test/DSN/Provider/Dir.pm M lib/DBI/Test/DSN/Provider/File.pm M lib/DBI/Test/List.pm Log Message: --- add initial version number (0.001) Commit: 392f20e0c8f07e101ab88d780787fb81583cdc0e https://github.com/perl5-dbi/DBI-Test/commit/392f20e0c8f07e101ab88d780787fb81583cdc0e Author: Jens Rehsack Date: 2013-09-18 (Wed, 18 Sep 2013) Changed paths: M lib/DBI/Mock.pm M lib/DBI/Test.pm M lib/DBI/Test/Case.pm M lib/DBI/Test/Case/attributes/PrintError.pm M lib/DBI/Test/Case/attributes/Warn.pm M lib/DBI/Test/Case/basic/bind_columns.pm M lib/DBI/Test/Case/basic/connect.pm M lib/DBI/Test/Case/basic/disconnect.pm M lib/DBI/Test/Case/basic/do.pm M lib/DBI/Test/Case/basic/execute.pm M lib/DBI/Test/Case/basic/prepare.pm M lib/DBI/Test/Case/basic/type_info.pm M lib/DBI/Test/Conf.pm M lib/DBI/Test/DSN/Provider.pm M lib/DBI/Test/DSN/Provider/Base.pm M lib/DBI/Test/DSN/Provider/Config.pm M lib/DBI/Test/DSN/Provider/Dir.pm M lib/DBI/Test/DSN/Provider/File.pm M lib/DBI/Test/List.pm Log Message: --- bump version to 0.002 Compare: https://github.com/perl5-dbi/DBI-Test/compare/849edd60ddc4...392f20e0c8f0
[perl5-dbi/DBI-Test] b30aca: Corrected perldoc statement in POD.
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: b30aca2c2c8376a9eea0833873c9d3bbb5f74b47 https://github.com/perl5-dbi/DBI-Test/commit/b30aca2c2c8376a9eea0833873c9d3bbb5f74b47 Author: Michiel Beijen Date: 2013-08-06 (Tue, 06 Aug 2013) Changed paths: M lib/DBI/Test.pm Log Message: --- Corrected perldoc statement in POD. Commit: 70ea3bc0416c6c1060a734ad313b52ae27de659c https://github.com/perl5-dbi/DBI-Test/commit/70ea3bc0416c6c1060a734ad313b52ae27de659c Author: Jens Rehsack Date: 2013-08-06 (Tue, 06 Aug 2013) Changed paths: M ChangeLog Log Message: --- fix release date of 0.001 Compare: https://github.com/perl5-dbi/DBI-Test/compare/5cf68fcc017e...70ea3bc0416c
[perl5-dbi/DBI-Test] 5cf68f: add lib/DBI/Test/DSN/Provider/Base.pm
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: 5cf68fcc017e162265b676bf7343878aa2832462 https://github.com/perl5-dbi/DBI-Test/commit/5cf68fcc017e162265b676bf7343878aa2832462 Author: Jens Rehsack Date: 2013-08-06 (Tue, 06 Aug 2013) Changed paths: M MANIFEST Log Message: --- add lib/DBI/Test/DSN/Provider/Base.pm
Some svn2git landed in github.com/perl5-dbi
/wave Before I stuck it next I imported my local svn to git and spread^Wpushed it to github. I know there're other places - but when perl5-dbi and libstatgrab lives there, it's not worth to find other hosters for the moment … Anyway - I tried to decide what should stay where, and I decided to put * DBD-Sys * Bundle-DBD-DBM * Bundle-Test-SQL-Statement into perl5-dbi room. I also created a room for utils, https://github.com/perl5-utils, where * Hash-MoreUtils * File-Find-Rule-LibMagic * File-Find-Rule-DirCompare * File-ConfigDir reside. I'll try to sync with Reini at YAPC::EU about List::MoreUtils, since I'm FIRSTCOME there but alias gave himself CO-MAINT and since then it's more or less uncontrolled growth and unmaintained. I plan to cut all co-maint for a while, but I've see that Reini investigated - if someone else want's to join our L::MU floor discussion, find and hit us ;) The rest of my imported stuff is in rehsack on github. If someone feels I should move MLDBM::Serializer::JSON to perl5-dbi or Template::DBI (which will be imported later - 'cause it was not on my broken disk), tell me. Cheers - and hopefully see many of you in Kiev -- Jens Rehsack pkgsrc, Perl5 rehs...@cpan.org
Re: State of DBI::Test
Am 06.08.2013 um 10:05 schrieb H.Merijn Brand :
> On Tue, 6 Aug 2013 09:46:39 +0200, "H.Merijn Brand"
> wrote:
>
>> On Mon, 5 Aug 2013 19:06:33 +0200, Jens Rehsack
>> wrote:
>>
>>> Hi,
>>>
>>> everybody who concern: from my point of view, DBI::Test is ready for first
>>> release to the world.
>>> It's not suitable to wait until it's perfect - the strategy is, to release
>>> early and hopefully often with usable extensions.
>>>
>>> If there're no objections, I upload DBI-Test-0.001.tar.gz tomorrow morning.
>>>
>>> For everybody who wants to see the state and how it's used, the dbi-test
>>> branches of DBI and SQL-Statement shows a rough how-to.
>>>
>>> Cheers
>>
>> Just a quick run on the git checkout using the default environment (no
>> bleading edge in $PERL5LIB) - I had to force-reinstall DBD::mysql :
>>
>> Just to see if all my database interfaces work as expected:
>>
>> Tie-Hash-DBD > make test
>> /pro/bin/perl5.18.0 "-MExtUtils::Command::MM" "-e" "test_harness(0,
>> 'blib/lib', 'blib/arch')" t/*.t
>> t/00_pod.t .. ok
>> t/01_pod.t .. ok
>> t/10_load.t . ok
>> t/20_SQLite.t ... ok
>> t/21_bulk.t . ok
>> t/22_stream.t ... ok
>> t/23_persist.t .. ok
>> t/25_SQLite.t ... ok
>> t/26_autoc.t ok
>> t/30_Pg.t ... ok
>> t/31_bulk.t . ok
>> t/32_stream.t ... ok
>> t/33_persist.t .. ok
>> t/35_Pg.t ... ok
>> t/36_autoc.t ok
>> t/40_CSV.t .. ok
>> t/41_bulk.t . ok
>> t/42_stream.t ... ok
>> t/43_persist.t .. ok
>> t/45_CSV.t .. ok
>> t/50_mysql.t ok
>> t/51_bulk.t . ok
>> t/52_stream.t ... ok
>> t/53_persist.t .. ok
>> t/55_mysql.t ok
>> t/56_autoc.t ok
>> t/60_Oracle.t ... skipped: Not a testable ORACLE env
>> t/61_bulk.t . skipped: Not a testable ORACLE env
>> t/62_stream.t ... skipped: Not a testable ORACLE env
>> t/63_persist.t .. skipped: Not a testable ORACLE env
>> t/65_Oracle.t ... skipped: Not a testable ORACLE env
>> t/66_autoc.t skipped: Not a testable ORACLE env
>
> In an Oracle env
>
> t/60_Oracle.t ... ok
> t/61_bulk.t . ok
> t/62_stream.t ... ok
> t/63_persist.t .. ok
> t/65_Oracle.t ... ok
> t/66_autoc.t ok
>
>> t/70_Unify.t skipped: Not a testable Unify env
>> t/71_bulk.t . skipped: Not a testable Unify env
>> t/72_stream.t ... skipped: Not a testable Unify env
>> t/73_persist.t .. skipped: Not a testable Unify env
>> t/75_Unify.t skipped: Not a testable Unify env
>> All tests successful.
>> Files=37, Tests=560, 44 wallclock secs ( 0.21 usr 0.05 sys + 6.74 cusr
>> 0.84 csys = 7.84 CPU)
>> Result: PASS
>>
>> So, DBI-Test-git …
>>
>> $ git pull --all
>> $ git remote prune origin
>> $ git clean -dfx
>> $ perl Makefile.PL
>> Checking if your kit is complete...
>> Looks good
>> Writing Makefile for DBI::Test
>> Writing MYMETA.yml and MYMETA.json
>> $ make test
>> :
>> t/basic/dvc_connect.t . ok
>> t/basic/dvc_disconnect.t .. ok
>> t/basic/dvd_connect.t . ok
>> t/basic/dvd_disconnect.t .. ok
>> t/basic/dve_connect.t . ok
>> t/basic/dve_disconnect.t .. ok
>> t/basic/dvf_connect.t . ok
>> t/basic/dvf_disconnect.t .. ok
>> t/basic/dvm_connect.t . install_driver(mysql) failed: Attempt to
>> reload DBD/mysql.pm aborted.
>> Compilation failed in require at (eval 158) line 3.
>
> With DBI->trace (4) in front of that connect:
>
> t/basic/dvm_connect.t . DBI 1.628 (PurePerl) dispatch trace level
> set to 4
> install_driver(mysql) failed: Attempt to reload DBD/mysql.pm aborted.
> Compilation failed in require at (eval 158) line 3.
>
> at /pro/3gl/CPAN/DBI-Test-git/blib/lib/DBI/Test.pm line 31.
>
> Why pure-perl? And /if/ pure-perl, there is probably no use in testing
> XS DBD's
Yeah - right. But without that, it doesn't load from DBI's Makefile.PL.
And no one answered in IRC :P
> With this change:
>
> diff --git a/lib/DBI/Mock.pm b/lib/DBI/Mock.pm
> index 510ce36..bcfcde4 100644
> --- a/lib/DBI/Mock.pm
> +++ b/lib/DBI/Mock.pm
> @@ -483,7 +483,7 @@ sub _miss_dbi
> defined $_have_dbi and return !$_have_dbi;
> $_have_dbi = 0;
> eval qq{
> - \$ENV{DBI_PUREPERL} = 2; # we only want to know if it's there ...
> +
Announcing DBI-Test 0.001
Hi, hereby I proudly announce DBI::Test-0.001. It's ready to be used for converting DBD tests as well as create generic basic DBI test. Cheers -- Jens Rehsack pkgsrc, Perl5 rehs...@cpan.org
[perl5-dbi/dbi] 735101: rename testcases to basename DBI::Test::Case
Branch: refs/heads/dbi-test Home: https://github.com/perl5-dbi/dbi Commit: 735101b43ae1899ddaa6dfc696401839f8b1fffa https://github.com/perl5-dbi/dbi/commit/735101b43ae1899ddaa6dfc696401839f8b1fffa Author: Jens Rehsack Date: 2013-08-05 (Mon, 05 Aug 2013) Changed paths: A lib/DBI/Test/Case/DBI/attributes/Active.pm A lib/DBI/Test/Case/DBI/attributes/ActiveKids.pm A lib/DBI/Test/Case/DBI/attributes/CachedKids.pm A lib/DBI/Test/Case/DBI/attributes/Executed.pm A lib/DBI/Test/Case/DBI/attributes/Kids.pm A lib/DBI/Test/Case/DBI/attributes/Type.pm R lib/DBI/Test/DBI/Case/attributes/Active.pm R lib/DBI/Test/DBI/Case/attributes/ActiveKids.pm R lib/DBI/Test/DBI/Case/attributes/CachedKids.pm R lib/DBI/Test/DBI/Case/attributes/Executed.pm R lib/DBI/Test/DBI/Case/attributes/Kids.pm R lib/DBI/Test/DBI/Case/attributes/Type.pm Log Message: --- rename testcases to basename DBI::Test::Case rename testcases to basename DBI::Test::Case, 'cause it's always prepended Commit: 7a4a8c44c13ac43973be08eb38c1419935f3bde8 https://github.com/perl5-dbi/dbi/commit/7a4a8c44c13ac43973be08eb38c1419935f3bde8 Author: Jens Rehsack Date: 2013-08-05 (Mon, 05 Aug 2013) Changed paths: M Makefile.PL A lib/DBI/Test/Case/DBI/simple/dbm.pm A lib/DBI/Test/Case/DBI/simple/file.pm A lib/DBI/Test/Case/DBI/simple/sql_engine.pm A lib/DBI/Test/DBI/Case.pm M lib/DBI/Test/DBI/Conf.pm A lib/DBI/Test/DBI/DSN/Provider/DBM.pm M lib/DBI/Test/DBI/List.pm R t/48dbi_dbd_sqlengine.t R t/49dbd_file.t R t/50dbm_simple.t R t/51dbm_file.t Log Message: --- complete DBI::Test bootstrap * add DBI::Test::DBI::Conf, List and Case * introduce DBI::Test::DBI::Provider::DSN::DBM for DBD::DBM variants * migrate basic DBD::File / DBD::DBM tests to DBI::Test Commit: f2e4627d22d035e40dfd44621245351326791672 https://github.com/perl5-dbi/dbi/commit/f2e4627d22d035e40dfd44621245351326791672 Author: Jens Rehsack Date: 2013-08-05 (Mon, 05 Aug 2013) Changed paths: M lib/DBD/DBM.pm Log Message: --- load dbm_* utility packages ... load dbm_* utility packages when determining version info Compare: https://github.com/perl5-dbi/dbi/compare/c54ef3fe45b6...f2e4627d22d0
[perl5-dbi/DBI-Test] 7d6045: provide ordering of DSN providers by relevance
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: 7d6045b6f142756b76d9c5a990e766337bce9f3b https://github.com/perl5-dbi/DBI-Test/commit/7d6045b6f142756b76d9c5a990e766337bce9f3b Author: Jens Rehsack Date: 2013-08-04 (Sun, 04 Aug 2013) Changed paths: M lib/DBI/Test/DSN/Provider.pm A lib/DBI/Test/DSN/Provider/Base.pm M lib/DBI/Test/DSN/Provider/Config.pm M lib/DBI/Test/DSN/Provider/Dir.pm M lib/DBI/Test/DSN/Provider/File.pm Log Message: --- provide ordering of DSN providers by relevance Commit: 1086c60b2ddfb1da6baca9b294a63f9e2092953f https://github.com/perl5-dbi/DBI-Test/commit/1086c60b2ddfb1da6baca9b294a63f9e2092953f Author: Jens Rehsack Date: 2013-08-04 (Sun, 04 Aug 2013) Changed paths: M lib/DBI/Test.pm Log Message: --- improve testnames for connecting/preparing Commit: 0b933383bd5c2571d0a4d2fee9001173d7240d77 https://github.com/perl5-dbi/DBI-Test/commit/0b933383bd5c2571d0a4d2fee9001173d7240d77 Author: Jens Rehsack Date: 2013-08-04 (Sun, 04 Aug 2013) Changed paths: M lib/DBI/Mock.pm Log Message: --- play / fix with set_err ... needs more love later Compare: https://github.com/perl5-dbi/DBI-Test/compare/e78f5ff21db7...0b933383bd5c
[perl5-dbi/DBI-Test] 80be4c: kick out buggy prepare test
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: 80be4c1b4b6586b0bd5acb31211a1e1812c04770 https://github.com/perl5-dbi/DBI-Test/commit/80be4c1b4b6586b0bd5acb31211a1e1812c04770 Author: Jens Rehsack Date: 2013-08-05 (Mon, 05 Aug 2013) Changed paths: M lib/DBI/Test/List.pm Log Message: --- kick out buggy prepare test Commit: 92cfaefec85c829938b767a0991928401410068e https://github.com/perl5-dbi/DBI-Test/commit/92cfaefec85c829938b767a0991928401410068e Author: Jens Rehsack Date: 2013-08-05 (Mon, 05 Aug 2013) Changed paths: M lib/DBI/Test/Case/basic/disconnect.pm Log Message: --- skip buggy prepare component Commit: 2d38349cd4057714f00376a03b5ba29e39615808 https://github.com/perl5-dbi/DBI-Test/commit/2d38349cd4057714f00376a03b5ba29e39615808 Author: Jens Rehsack Date: 2013-08-05 (Mon, 05 Aug 2013) Changed paths: M lib/DBI/Test/DSN/Provider.pm Log Message: --- fix plugin handling Commit: 571ed6602fb4eea8aac15bd6511f01bb2bd8a0c3 https://github.com/perl5-dbi/DBI-Test/commit/571ed6602fb4eea8aac15bd6511f01bb2bd8a0c3 Author: Jens Rehsack Date: 2013-08-05 (Mon, 05 Aug 2013) Changed paths: M lib/DBI/Test.pm Log Message: --- add more tests, especially for failing case Commit: de1d75df16dc2752ae5cd7c10634e6808cfdf2c2 https://github.com/perl5-dbi/DBI-Test/commit/de1d75df16dc2752ae5cd7c10634e6808cfdf2c2 Author: Jens Rehsack Date: 2013-08-05 (Mon, 05 Aug 2013) Changed paths: M lib/DBI/Mock.pm Log Message: --- workaround for DBI configuration phase Commit: 62163b34d768addcc9e205ef083d794e2675a533 https://github.com/perl5-dbi/DBI-Test/commit/62163b34d768addcc9e205ef083d794e2675a533 Author: Jens Rehsack Date: 2013-08-05 (Mon, 05 Aug 2013) Changed paths: M lib/DBI/Test/Conf.pm Log Message: --- improve test case generation * allow test case dsn's being variated based on test's requirement (require_extended method) * distinguish between init_stub and cleanup_stub for test variants Compare: https://github.com/perl5-dbi/DBI-Test/compare/3b8e67e0cad1...62163b34d768
[perl5-dbi/DBI-Test] 3b8e67: perltidy
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: 3b8e67e0cad1448b10140720a712ffd6a8e0c263 https://github.com/perl5-dbi/DBI-Test/commit/3b8e67e0cad1448b10140720a712ffd6a8e0c263 Author: Jens Rehsack Date: 2013-08-05 (Mon, 05 Aug 2013) Changed paths: M lib/DBI/Test/Conf.pm Log Message: --- perltidy
State of DBI::Test
Hi, everybody who concern: from my point of view, DBI::Test is ready for first release to the world. It's not suitable to wait until it's perfect - the strategy is, to release early and hopefully often with usable extensions. If there're no objections, I upload DBI-Test-0.001.tar.gz tomorrow morning. For everybody who wants to see the state and how it's used, the dbi-test branches of DBI and SQL-Statement shows a rough how-to. Cheers -- Jens Rehsack pkgsrc, Perl5 rehs...@cpan.org
[perl5-dbi/DBI-Test] 95491a: provide unified DBI(::Mock)? test case detector
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: 95491afd47c4bc57ac439cee1be461193755ce25 https://github.com/perl5-dbi/DBI-Test/commit/95491afd47c4bc57ac439cee1be461193755ce25 Author: Jens Rehsack Date: 2013-08-04 (Sun, 04 Aug 2013) Changed paths: M lib/DBI/Test/Case.pm Log Message: --- provide unified DBI(::Mock)? test case detector Commit: 6e803546405186864a09203d29cd1aca91f78dcd https://github.com/perl5-dbi/DBI-Test/commit/6e803546405186864a09203d29cd1aca91f78dcd Author: Jens Rehsack Date: 2013-08-04 (Sun, 04 Aug 2013) Changed paths: M lib/DBI/Test/Conf.pm Log Message: --- fix filter_drivers etc. using $options, too Commit: 39ae1f66deb803bfceda6bbaeb4b5cf880b46013 https://github.com/perl5-dbi/DBI-Test/commit/39ae1f66deb803bfceda6bbaeb4b5cf880b46013 Author: Jens Rehsack Date: 2013-08-04 (Sun, 04 Aug 2013) Changed paths: M MANIFEST M MANIFEST.SKIP M Makefile.PL M lib/DBI/Test/Conf.pm Log Message: --- try how to prevent distributing generated tests Compare: https://github.com/perl5-dbi/DBI-Test/compare/4718570be270...39ae1f66deb8
[perl5-dbi/DBI-Test] 01b70b: fix is_test_for_* features and perltidy
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: 01b70bd14ff557fd35f1fe7e941a70b2a5e9c000 https://github.com/perl5-dbi/DBI-Test/commit/01b70bd14ff557fd35f1fe7e941a70b2a5e9c000 Author: Jens Rehsack Date: 2013-08-04 (Sun, 04 Aug 2013) Changed paths: M lib/DBI/Test/Case.pm Log Message: --- fix is_test_for_* features and perltidy Commit: e78f5ff21db7fdd74479a09f1c1035bc1a62ee89 https://github.com/perl5-dbi/DBI-Test/commit/e78f5ff21db7fdd74479a09f1c1035bc1a62ee89 Author: Jens Rehsack Date: 2013-08-04 (Sun, 04 Aug 2013) Changed paths: M lib/DBI/Mock.pm Log Message: --- take some DBI methods for generic exection ... take some DBI methods for generic exection of statements and fix RootClass behavior Compare: https://github.com/perl5-dbi/DBI-Test/compare/39ae1f66deb8...e78f5ff21db7
[perl5-dbi/DBI-Test] 02b061: fix broken fix of extracting DBD class name ...
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: 02b0619e70c8faa8e1dd344fa8942111d230fdf9 https://github.com/perl5-dbi/DBI-Test/commit/02b0619e70c8faa8e1dd344fa8942111d230fdf9 Author: Jens Rehsack Date: 2013-08-01 (Thu, 01 Aug 2013) Changed paths: M lib/DBI/Test/DSN/Provider/Dir.pm Log Message: --- fix broken fix of extracting DBD class name ... fix broken fix of extracting DBD class name and remove debugging carp. Commit: c1461d44e68df72be60f1ac097304f21b391d6a7 https://github.com/perl5-dbi/DBI-Test/commit/c1461d44e68df72be60f1ac097304f21b391d6a7 Author: Jens Rehsack Date: 2013-08-01 (Thu, 01 Aug 2013) Changed paths: A lib/DBI/Test/Case.pm M lib/DBI/Test/Case/basic/connect.pm M lib/DBI/Test/Case/basic/disconnect.pm M lib/DBI/Test/Case/basic/prepare.pm Log Message: --- don't do tests with DBI::Mock and real DBD's Compare: https://github.com/perl5-dbi/DBI-Test/compare/cde5dc9e4785...c1461d44e68d
[perl5-dbi/dbi] 2f21dd: handle aliasing of STORE'd attributes for looking ...
Branch: refs/heads/dbi-test Home: https://github.com/perl5-dbi/dbi Commit: 2f21ddff0707ac6d236ce54af91931f4e863ecae https://github.com/perl5-dbi/dbi/commit/2f21ddff0707ac6d236ce54af91931f4e863ecae Author: Jens Rehsack Date: 2013-05-10 (Fri, 10 May 2013) Changed paths: M lib/DBI/DBD/SqlEngine.pm Log Message: --- handle aliasing of STORE'd attributes for looking up into read_only attribute list ... Commit: fac5acde78af6f78fc487c688223671bdfe73ff0 https://github.com/perl5-dbi/dbi/commit/fac5acde78af6f78fc487c688223671bdfe73ff0 Author: H.Merijn Brand - Tux Date: 2013-05-10 (Fri, 10 May 2013) Changed paths: M lib/DBD/DBM.pm M lib/DBI/DBD/SqlEngine.pm M lib/DBI/DBD/SqlEngine/Developers.pod Log Message: --- pod text/link was reversed in a few cases $ perldoc perlpod To control what text is used for display, you use ""L"", as in: * "L" Link this text to that manual page. E.g., "L" * "L" or "L" Link this text to that section in that manual page. E.g., "L" * "L" or "L" or "L" Link this text to that section in this manual page. E.g., "L" Commit: 3e3ad7125d7a7bd3175a1b27f4eba5bf85f89699 https://github.com/perl5-dbi/dbi/commit/3e3ad7125d7a7bd3175a1b27f4eba5bf85f89699 Author: Tim Bunce Date: 2013-05-15 (Wed, 15 May 2013) Changed paths: M Changes M DBI.pm Log Message: --- prep 1.626 release Commit: 1db09f4ec7840795795f1d1a8c11c153390f52ed https://github.com/perl5-dbi/dbi/commit/1db09f4ec7840795795f1d1a8c11c153390f52ed Author: Tim Bunce Date: 2013-05-15 (Wed, 15 May 2013) Changed paths: M Changes M t/48dbi_dbd_sqlengine.t Log Message: --- Fixed skip() count arg in t/48dbi_dbd_sqlengine.t Commit: 246adb9d2380daf63fbfff643715fdf5dc767f57 https://github.com/perl5-dbi/dbi/commit/246adb9d2380daf63fbfff643715fdf5dc767f57 Author: Tim Bunce Date: 2013-05-15 (Wed, 15 May 2013) Changed paths: M Makefile.PL R git-svn-vsn.pl Log Message: --- remove git-svn-vsn.pl utility that's no longer needed Commit: 0b3fe3d8b14c2280e27032c8ea52d1a3c4c133c1 https://github.com/perl5-dbi/dbi/commit/0b3fe3d8b14c2280e27032c8ea52d1a3c4c133c1 Author: Tim Bunce Date: 2013-05-16 (Thu, 16 May 2013) Changed paths: M lib/DBI/SQL/Nano.pm Log Message: --- Fixed VERSION regression in DBI::SQL::Nano Looks like the previous change "Apply the git-svn-vsn.pl script to "fix" the svn keywords like Id and Revision" wasn't done quite right. The VERSION is fixed now we're no longer using svn. I've just bumped the number. Commit: 26b85388b27b7a805876b732e25662d769da11b0 https://github.com/perl5-dbi/dbi/commit/26b85388b27b7a805876b732e25662d769da11b0 Author: Tim Bunce Date: 2013-05-16 (Thu, 16 May 2013) Changed paths: M Changes M DBI.pm Log Message: --- Prep 1.627 release Commit: 79592f16724529ff7ed2f9075a6bcd5d064babb6 https://github.com/perl5-dbi/dbi/commit/79592f16724529ff7ed2f9075a6bcd5d064babb6 Author: David Steinbrunner Date: 2013-05-17 (Fri, 17 May 2013) Changed paths: M DBI.pm M lib/DBI/FAQ.pm M lib/DBI/Gofer/Execute.pm M lib/DBI/Profile.pm M lib/DBI/ProfileData.pm M lib/DBI/ProfileDumper.pm M lib/DBI/ProxyServer.pm M lib/DBI/PurePerl.pm M lib/DBI/W32ODBC.pm M lib/Win32/DBIODBC.pm Log Message: --- typo fixes a little intuition used in some changes so please double check Commit: 85a1c0b246fe0a2fb30ac7df237efef0f5651fe1 https://github.com/perl5-dbi/dbi/commit/85a1c0b246fe0a2fb30ac7df237efef0f5651fe1 Author: H.Merijn Brand Date: 2013-05-17 (Fri, 17 May 2013) Changed paths: M DBI.pm M lib/DBI/FAQ.pm M lib/DBI/Gofer/Execute.pm M lib/DBI/Profile.pm M lib/DBI/ProfileData.pm M lib/DBI/ProfileDumper.pm M lib/DBI/ProxyServer.pm M lib/DBI/PurePerl.pm M lib/DBI/W32ODBC.pm M lib/Win32/DBIODBC.pm Log Message: --- Merge pull request #1 from dsteinbrunner/master typo fixes Commit: 94bae38fb14777ad587d8cd343cf39f3990d6cfc https://github.com/perl5-dbi/dbi/commit/94bae38fb14777ad587d8cd343cf39f3990d6cfc Author: H.Merijn Brand - Tux Date: 2013-05-18 (Sat, 18 May 2013) Changed paths: M Changes M DBI.pm Log Message: --- Change DBI's docs from svn to git Note that the Roadmap has moved to Old and is thus not supposed to be available. I /think/ that "Director (CTO) of Ingeneering" should be "Director (CTO) of Engeneering" Commit: 3f4d5efaed8f2fa89ad6fd9b265d60f557bfad2e https://github.com/perl5-dbi/dbi/commit/3f4d5efaed8f2fa89ad6fd9b265d60f557bfad2e Author:
[perl5-dbi/DBI-Test] 471857: merge *.bak pattern from SQL::Statement
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: 4718570be270e1a88269b7e94dc1ec8e9abdee3c https://github.com/perl5-dbi/DBI-Test/commit/4718570be270e1a88269b7e94dc1ec8e9abdee3c Author: Jens Rehsack Date: 2013-08-01 (Thu, 01 Aug 2013) Changed paths: M .gitignore Log Message: --- merge *.bak pattern from SQL::Statement
[perl5-dbi/DBI-Test] b3c431: fix typo creating simple DSN's
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: b3c43135035234777b3df3aa4a550a1f2ba2ad13 https://github.com/perl5-dbi/DBI-Test/commit/b3c43135035234777b3df3aa4a550a1f2ba2ad13 Author: Jens Rehsack Date: 2013-08-01 (Thu, 01 Aug 2013) Changed paths: M lib/DBI/Test/Conf.pm Log Message: --- fix typo creating simple DSN's Commit: cde5dc9e47856a01f4d3910817953db55b989158 https://github.com/perl5-dbi/DBI-Test/commit/cde5dc9e47856a01f4d3910817953db55b989158 Author: Jens Rehsack Date: 2013-08-01 (Thu, 01 Aug 2013) Changed paths: M lib/DBI/Test/DSN/Provider.pm M lib/DBI/Test/DSN/Provider/Config.pm M lib/DBI/Test/DSN/Provider/Dir.pm Log Message: --- implement simple Dir provider for DBD::File based implement simple Dir provider for DBD::File based DBD's Compare: https://github.com/perl5-dbi/DBI-Test/compare/e8af4011e2b7...cde5dc9e4785
[perl5-dbi/DBI-Test] e8af40: extend prefix generation by driver based dsn
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: e8af4011e2b734b96d3c1c13c73b970385e8de44 https://github.com/perl5-dbi/DBI-Test/commit/e8af4011e2b734b96d3c1c13c73b970385e8de44 Author: Jens Rehsack Date: 2013-07-31 (Wed, 31 Jul 2013) Changed paths: M lib/DBI/Test/Conf.pm Log Message: --- extend prefix generation by driver based dsn Since it makes sense to decouple 1600 tests in SQL-Statement/t/06virtual.t by separating it into one file per used DBD, or clean up DBI/t/52dbm_complex.t, we now have the opportunity to do that. Pitfall - it defaultly generates all variants even when they are not necessary (eg. for connection test, it doesn't connect better with MLDBM or BerkeleyDB).
[perl5-dbi/DBI-Test] db6be1: fix minor nits
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: db6be10418f3b1051be6e7baba5aee17c4a6593d https://github.com/perl5-dbi/DBI-Test/commit/db6be10418f3b1051be6e7baba5aee17c4a6593d Author: Jens Rehsack Date: 2013-07-31 (Wed, 31 Jul 2013) Changed paths: M MANIFEST.SKIP Log Message: --- fix minor nits Commit: 0d7644cabf300c340641ba83d24dc0ed8aac0954 https://github.com/perl5-dbi/DBI-Test/commit/0d7644cabf300c340641ba83d24dc0ed8aac0954 Author: Jens Rehsack Date: 2013-07-31 (Wed, 31 Jul 2013) Changed paths: M MANIFEST Log Message: --- regenerate MANIFEST Commit: 16c0e14bf819209c3d1fafbceafa1497f5d5cb01 https://github.com/perl5-dbi/DBI-Test/commit/16c0e14bf819209c3d1fafbceafa1497f5d5cb01 Author: Jens Rehsack Date: 2013-07-31 (Wed, 31 Jul 2013) Changed paths: M Makefile.PL M lib/DBI/Test/Conf.pm Log Message: --- respect with of Tim Bunce that AUTHOR_TESTS will ... Respect with of Tim Bunce that AUTHOR_TESTS will be generated into xt/ but to t/ It's currently on MANIFEST.SKIP to care them not in distribution Compare: https://github.com/perl5-dbi/DBI-Test/compare/4ac7e155fcbf...16c0e14bf819
[perl5-dbi/DBI-Test] 1cbb32: mock installed_/available_drivers, too
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: 1cbb32379a6ac05d6a16a6e58d66e2be1c26a6fb https://github.com/perl5-dbi/DBI-Test/commit/1cbb32379a6ac05d6a16a6e58d66e2be1c26a6fb Author: Jens Rehsack Date: 2013-07-31 (Wed, 31 Jul 2013) Changed paths: M lib/DBI/Mock.pm Log Message: --- mock installed_/available_drivers, too but only have DBD::NullP - nothing else
[perl5-dbi/DBI-Test] a2d1b2: create separate tests for DBI and DBI::Mock ...
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: a2d1b22d134be0ca353e0f0b312fb14da24c798e https://github.com/perl5-dbi/DBI-Test/commit/a2d1b22d134be0ca353e0f0b312fb14da24c798e Author: Jens Rehsack Date: 2013-07-31 (Wed, 31 Jul 2013) Changed paths: M lib/DBI/Test/Conf.pm Log Message: --- create separate tests for DBI and DBI::Mock ... create separate tests for DBI and DBI::Mock only when DBI is found
[perl5-dbi/DBI-Test] 259b89: perltidy lib/DBI/Mock.pm
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: 259b8946d0112c630dfc1d1807824fd6305ca46c https://github.com/perl5-dbi/DBI-Test/commit/259b8946d0112c630dfc1d1807824fd6305ca46c Author: Jens Rehsack Date: 2013-07-10 (Wed, 10 Jul 2013) Changed paths: M lib/DBI/Mock.pm Log Message: --- perltidy lib/DBI/Mock.pm Commit: 13dfe705941275821b8e595a44fe53e7eef03e39 https://github.com/perl5-dbi/DBI-Test/commit/13dfe705941275821b8e595a44fe53e7eef03e39 Author: Jens Rehsack Date: 2013-07-10 (Wed, 10 Jul 2013) Changed paths: M lib/DBI/Mock.pm Log Message: --- fix DBI::Mock quirks Commit: 4ac7e155fcbf0b8e6c33dd87e4ef027e2132f5b5 https://github.com/perl5-dbi/DBI-Test/commit/4ac7e155fcbf0b8e6c33dd87e4ef027e2132f5b5 Author: Jens Rehsack Date: 2013-07-10 (Wed, 10 Jul 2013) Changed paths: M lib/DBI/Test/Case/basic/disconnect.pm M lib/DBI/Test/Case/basic/prepare.pm M lib/DBI/Test/List.pm Log Message: --- enable basic::disconnect and basic::prepare Compare: https://github.com/perl5-dbi/DBI-Test/compare/77fd156c61ee...4ac7e155fcbf
[perl5-dbi/DBI-Test] 16aff1: rename dns provider method into "get_dsn_creds"
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: 16aff14fd2ac2e7f2859902019df1b86c519f580 https://github.com/perl5-dbi/DBI-Test/commit/16aff14fd2ac2e7f2859902019df1b86c519f580 Author: Jens Rehsack Date: 2013-07-10 (Wed, 10 Jul 2013) Changed paths: M lib/DBI/Test/Conf.pm M lib/DBI/Test/DSN/Provider.pm Log Message: --- rename dns provider method into "get_dsn_creds" Commit: 77fd156c61ee2a0b64b9ba13146e8f5c27fd2bf4 https://github.com/perl5-dbi/DBI-Test/commit/77fd156c61ee2a0b64b9ba13146e8f5c27fd2bf4 Author: Jens Rehsack Date: 2013-07-10 (Wed, 10 Jul 2013) Changed paths: M lib/DBI/Test/DSN/Provider/Config.pm Log Message: --- implement best guess for DSN::Provider::Config Compare: https://github.com/perl5-dbi/DBI-Test/compare/ec8bf68367a5...77fd156c61ee
[perl5-dbi/DBI-Test] 5ddc64: MYMETA.yml -> MYMETA.*
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: 5ddc6413839a0d6a003495feb2a5a609817a0bb5 https://github.com/perl5-dbi/DBI-Test/commit/5ddc6413839a0d6a003495feb2a5a609817a0bb5 Author: Jens Rehsack Date: 2013-07-10 (Wed, 10 Jul 2013) Changed paths: M .gitignore Log Message: --- MYMETA.yml -> MYMETA.* Commit: d4f595fc137ec95c4353e2477e82a8f096e5758b https://github.com/perl5-dbi/DBI-Test/commit/d4f595fc137ec95c4353e2477e82a8f096e5758b Author: Jens Rehsack Date: 2013-07-10 (Wed, 10 Jul 2013) Changed paths: M lib/DBI/Test.pm M lib/DBI/Test/Case/basic/connect.pm M lib/DBI/Test/Conf.pm A lib/DBI/Test/DSN/Provider.pm A lib/DBI/Test/DSN/Provider/Config.pm A lib/DBI/Test/DSN/Provider/Dir.pm A lib/DBI/Test/DSN/Provider/File.pm Log Message: --- slightly larger test case improvement(s) - run_test method enforced by generated *.t files - DSN::Provider used to deliver datasource-names and config for test - introduce some DBI test methods like connect_ok - improve *.t generation Commit: ce3913f7d269596d660a3f89acdac2781c27dc17 https://github.com/perl5-dbi/DBI-Test/commit/ce3913f7d269596d660a3f89acdac2781c27dc17 Author: Jens Rehsack Date: 2013-07-10 (Wed, 10 Jul 2013) Changed paths: M lib/DBI/Test/Case/basic/disconnect.pm M lib/DBI/Test/Case/basic/prepare.pm Log Message: --- perltidy Commit: ec8bf68367a5ac8c4bc0bc4de627e20235ec https://github.com/perl5-dbi/DBI-Test/commit/ec8bf68367a5ac8c4bc0bc4de627e20235ec Author: Jens Rehsack Date: 2013-07-10 (Wed, 10 Jul 2013) Changed paths: M lib/DBI/Test.pm Log Message: --- add pod for connect_not_ok Compare: https://github.com/perl5-dbi/DBI-Test/compare/17f8faabeec7...ec8bf68367a5
Re: DBI::Test next steps ...
Am 10.07.2013 um 14:33 schrieb Jens Rehsack : > Hi Tim, Hi Tim, Peter, Merijn, > you offered help to DBI::Test. Meanwhile I found a tuit under my table and > hacked a bit forward (state: DBI::Test::DSN::Provider needs driver impl. - but > I can/will do it asap - hints like "move them to DSN::Provider::Driver::*" for > … are welcome). > > Next steps should be: review existing tests in DBI::Test and strip them down > to let them do what they should do. Hereby some help would be great. > > I'm currently on disconnect and prepare tests, but I can't finish them without > loosing my goal (infrastructure of DBI::Test). So here I definitively need > hacking help. > > My next goals should be creating however test cases for and in DBI itself and > SQL::Statement. > > Please also feedback about code / doc if there is something missing. Peter / Merijn - you both said, you would care about config file etc. Please do so :) Further, I rewrote the most important 3 test cases from Joakim (no one else cares :/), but I would at the moment ignore the rest for going to DBI and SQL::Statement. My next goal I want to reach for DBI::Test are: - rewrite dbi/t/10examp.t, 12quote.t, … (choosing some nice ones …) - rewrite and flexible dbi/t/49..52*.t (DBD::File and DBD::DBM tests) - rewrite some SQL::Statement tests using DBI::Test (especially for extending the xy_ok() stuff - with is_deeply support etc. @Tim, Peter (and when back from holiday Merijn): There is help needed! First in thinking, than in doing ;) Cheers -- Jens Rehsack pkgsrc, Perl5 rehs...@cpan.org
DBI::Test next steps ...
Hi Tim, you offered help to DBI::Test. Meanwhile I found a tuit under my table and hacked a bit forward (state: DBI::Test::DSN::Provider needs driver impl. - but I can/will do it asap - hints like "move them to DSN::Provider::Driver::*" for … are welcome). Next steps should be: review existing tests in DBI::Test and strip them down to let them do what they should do. Hereby some help would be great. I'm currently on disconnect and prepare tests, but I can't finish them without loosing my goal (infrastructure of DBI::Test). So here I definitively need hacking help. My next goals should be creating however test cases for and in DBI itself and SQL::Statement. Please also feedback about code / doc if there is something missing. Cheers -- Jens Rehsack pkgsrc, Perl5 rehs...@cpan.org
[perl5-dbi/DBI-Test] 17f8fa: Improve DESCRIPTION
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: 17f8faabeec703c5db189aa59821ff2755da1b92 https://github.com/perl5-dbi/DBI-Test/commit/17f8faabeec703c5db189aa59821ff2755da1b92 Author: Jens Rehsack Date: 2013-07-01 (Mon, 01 Jul 2013) Changed paths: M lib/DBI/Test.pm Log Message: --- Improve DESCRIPTION
