[Monetdb-developers] MonetDB::CLI: MapiLib alternatives
I'd like to add a more perlish layer around MapiLib (working title: MonetDB::CLI). This may look like: my $Cxn = MonetDB::CLI->connect( ... ); my $Req = $Cxn->query('select * from env'); while ( my $Cnt = $Req->fetch_row ) { print $Req->fetch_field( $_ ) for 0 .. $Cnt-1; } Still much in the spirit of Mapi, but handles are now objects (with destructors), functions are methods and the methods can throw exceptions. Once we have such an interface, additional implementations are possible. For instance, a XS module could skip the MapiLib layer and use libMapi directly. Later on, an implementation for MCL will be added (I hope) - either in pure perl or on top of libMCL (in case such a library will emerge). Of course, I'd like to use this new interface from DBD::monetdb to be able to choose between various implementations and to ease the transition to MCL. On the downside: additional modules means additional installation efforts. Especially the people resposible for the RPM's will be affected. If this sounds too screwy, it's now the chance to stop me ;-) Steffen
On Mon, Sep 05, 2005 at 04:33:06PM +0200, Steffen Goeldner wrote:
I'd like to add a more perlish layer around MapiLib (working title: MonetDB::CLI). This may look like:
my $Cxn = MonetDB::CLI->connect( ... ); my $Req = $Cxn->query('select * from env'); while ( my $Cnt = $Req->fetch_row ) { print $Req->fetch_field( $_ ) for 0 .. $Cnt-1; }
Still much in the spirit of Mapi, but handles are now objects (with destructors), functions are methods and the methods can throw exceptions. Once we have such an interface, additional implementations are possible. For instance, a XS module could skip the MapiLib layer and use libMapi directly. Later on, an implementation for MCL will be added (I hope) - either in pure perl or on top of libMCL (in case such a library will emerge). Of course, I'd like to use this new interface from DBD::monetdb to be able to choose between various implementations and to ease the transition to MCL. On the downside: additional modules means additional installation efforts. Especially the people resposible for the RPM's will be affected. If this sounds too screwy, it's now the chance to stop me ;-)
Go ahead, have fun with this layer. I don't think the rpm will be a problem. Niels
Steffen
------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
-- Niels Nes, Centre for Mathematics and Computer Science (CWI) Kruislaan 413, 1098 SJ Amsterdam, The Netherlands room C0.02, phone ++31 20 592-4098, fax ++31 20 592-4312 url: http://www.cwi.nl/~niels e-mail: Niels.Nes@cwi.nl
Steffen Goeldner wrote:
I'd like to add a more perlish layer around MapiLib (working title: MonetDB::CLI). This may look like:
my $Cxn = MonetDB::CLI->connect( ... ); my $Req = $Cxn->query('select * from env'); while ( my $Cnt = $Req->fetch_row ) { print $Req->fetch_field( $_ ) for 0 .. $Cnt-1; }
Still much in the spirit of Mapi, but handles are now objects (with destructors), functions are methods and the methods can throw exceptions. Once we have such an interface, additional implementations are possible. For instance, a XS module could skip the MapiLib layer and use libMapi directly. Later on, an implementation for MCL will be added (I hope) - either in pure perl or on top of libMCL (in case such a library will emerge). Of course, I'd like to use this new interface from DBD::monetdb to be able to choose between various implementations and to ease the transition to MCL. On the downside: additional modules means additional installation efforts. Especially the people resposible for the RPM's will be affected. If this sounds too screwy, it's now the chance to stop me ;-)
Sounds a bit like the CMapi module in the src/mapi/clients/python/Cimpl directory. In other words, we already have something similar for Python, so no reason to not also do it for Perl. -- Sjoerd Mullender
Sjoerd Mullender wrote:
Steffen Goeldner wrote:
I'd like to add a more perlish layer around MapiLib (working title: MonetDB::CLI). This may look like:
Sounds a bit like the CMapi module in the src/mapi/clients/python/Cimpl directory.
Exactly! Probably, I don't wrap all Mapi functions, but concentrate on those I need in DBD::monetdb. And I'll keep an eye on MCL. Regarding CMapi.py (from an amateurish point of view): result_error() is never used. Shouldn't the query*() methods (and maybe others) check for these errors? Steffen
Steffen Goeldner wrote:
Sjoerd Mullender wrote:
Steffen Goeldner wrote:
I'd like to add a more perlish layer around MapiLib (working title: MonetDB::CLI). This may look like:
Sounds a bit like the CMapi module in the src/mapi/clients/python/Cimpl directory.
Exactly! Probably, I don't wrap all Mapi functions, but concentrate on those I need in DBD::monetdb. And I'll keep an eye on MCL. Regarding CMapi.py (from an amateurish point of view): result_error() is never used. Shouldn't the query*() methods (and maybe others) check for these errors?
I think the code for result sets is newer than CMapi.py. I guess I only did the semi-automatic translation from the Mapi interface to CMapi. I think that result_error should not check for errors but just return the value (string) obtained by calling into the library, just as error_str() does. And indeed, this method should probably be called to get the error strings when there is an error in a query. I'll have to see when and where that needs to be done. -- Sjoerd Mullender
Steffen Goeldner wrote:
I'd like to add a more perlish layer around MapiLib (working title: MonetDB::CLI). This may look like:
FYI, these modules entered CPAN today: http://search.cpan.org/search?query=MonetDB;mode=module Steffen
participants (3)
-
Niels Nes -
Sjoerd Mullender -
Steffen Goeldner