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.

Jens Rehsack

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdbi-dev @
postedJan 27, '15 at 9:26a
activeJan 27, '15 at 9:26a

1 user in discussion

Jens Rehsack: 1 post



site design / logo © 2019 Grokbase