Søren
I think you have a very good idea there.
DBI has pretty strong text access now, making DBI::AnyData deprecatable
- and non-DBI AnyData somewhat dubious (its really just a tied-hash API)
So making an Augeas (like?) <-> DBI bridge could be very interesting indeed
Sven
(and atm, i'm pottering around in golang and docker, so not much help)
On 01/11/13 10:41, Gmail wrote:
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?
Regards,
-- Søren
On 2013/10/12, at 17:39, Jens Rehsack <rehs...@gmail.com> wrote:
Am 12.10.2013 um 00:49 schrieb Sven Dowideit <svendowid...@home.org.au>:
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 <sauberso...@gmail.com>:
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
