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 > > >
