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

-- Søren

Search Discussions

  • Jens Rehsack at Oct 11, 2013 at 2:10 pm

    Am 07.10.2013 um 02:37 schrieb Søren Døssing <saubersound@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
    rehsack@cpan.org
  • Sven Dowideit at Oct 11, 2013 at 10:49 pm
    Heya Søren and Jens,

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

    Sven

    On 12/10/13 00:10, Jens Rehsack wrote:
    Am 07.10.2013 um 02:37 schrieb Søren Døssing <saubersound@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 at Oct 12, 2013 at 8:39 am

    Am 12.10.2013 um 00:49 schrieb Sven Dowideit <svendowideit@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 <saubersound@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
    rehsack@cpan.org
  • Gmail at Nov 1, 2013 at 12:41 am
    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 wrote:

    Am 12.10.2013 um 00:49 schrieb Sven Dowideit <svendowideit@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 <saubersound@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
    rehsack@cpan.org

  • Sven Dowideit at Nov 1, 2013 at 11:05 am
    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 wrote:

    Am 12.10.2013 um 00:49 schrieb Sven Dowideit <svendowideit@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 <saubersound@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
    rehsack@cpan.org

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdbi-dev @
categoriesperl
postedOct 7, '13 at 12:38a
activeNov 1, '13 at 11:05a
posts6
users3
websitedbi.perl.org

People

Translate

site design / logo © 2019 Grokbase