Am 18.02.2014 um 13:56 schrieb Tim Bunce <tim.bu...@pobox.com>:
> On Tue, Feb 18, 2014 at 09:35:20AM +0100, Jens Rehsack wrote:
>> Am 18.02.2014 um 00:37 schrieb Tim Bunce <tim.bu...@pobox.com>:
>>
>>> 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
