[MonetDB-users] Perl and MonetDB Xquery
LS, As Perl is one of the main programming languages at our institute, I tried the Perl API with MonetDB-Xquery. I succeeded with sending mil statements (with the language parameter set to 'mil') to the server and getting the correct answer, but xqueries failed (with the language parameter set to 'xquery'). This was not a complete surprise as the documentation seems to be ambiguous ("MonetDB/XQuery for POSIX (Linux/Unix) platforms currently only supports MAPI (MonetDB API) to communicate with the XQuery engine."). Following the link to the API's: "Perl binding of the simple Monet API (Mapi) for MIL/SQL database interaction". So, I would like to know if my assumption that currently no xqueries are supported by the Perl API is correct. Peter
Peter van der Kamp wrote:
As Perl is one of the main programming languages at our institute,
Nice to hear! (Thought the Netherlands is more Python biased.)
I tried the Perl API with MonetDB-Xquery. I succeeded with sending mil statements (with the language parameter set to 'mil') to the server and getting the correct answer, but xqueries failed (with the language parameter set to 'xquery'). This was not a complete surprise as the documentation seems to be ambiguous ("MonetDB/XQuery for POSIX (Linux/Unix) platforms currently only supports MAPI (MonetDB API) to communicate with the XQuery engine."). Following the link to the API's: "Perl binding of the simple Monet API (Mapi) for MIL/SQL database interaction". So, I would like to know if my assumption that currently no xqueries are supported by the Perl API is correct.
DBD::monetdb restricts the language parameter: die "!ERROR languages permitted are 'sql', 'mal', and 'mil'\n" unless ($lang eq 'mal' || $lang eq 'sql' || $lang eq 'mil'); Drop these lines if they get in the way. There are a few conditionals in the code (to switch behavior between 'sql' and 'mil'). Maybe you need additional conditionals for 'xquery'. Thenceforward you have to fight for yourself. (Last time I battled with hierarchical databases in 1969;-) Of course, I'll help to incorporate necessary changes into the module. Steffen P.S.: For testing purposes, it may be easier to use plain MapiLib: use MapiLib; my $mapi = MapiLib::mapi_connect('localhost', 50000,'','','') or die $!; my $hdl = MapiLib::mapi_query( $mapi,'env();'); die MapiLib::mapi_error_str( $mapi ) if MapiLib::mapi_error( $mapi ); while ( MapiLib::mapi_fetch_row( $hdl ) ) { print MapiLib::mapi_fetch_field( $hdl, 0 ); }
Steffen Goeldner wrote:
DBD::monetdb restricts the language parameter:
die "!ERROR languages permitted are 'sql', 'mal', and 'mil'\n" unless ($lang eq 'mal' || $lang eq 'sql' || $lang eq 'mil');
Drop these lines if they get in the way. There are a few conditionals in the code (to switch behavior between 'sql' and 'mil'). Maybe you need additional conditionals for 'xquery'. Thenceforward you have to fight for yourself. (Last time I battled with hierarchical databases in 1969;-) Of course, I'll help to incorporate necessary changes into the module.
Steffen, is it of any use to you to know that XML:DB (a Java based XML kind of JDBC driver) is based on JDBC, and that for that I had to make MonetDB/XQuery able to talk with the JDBC driver? I made this JDBC/XQuery 'marriage' by letting the XQuery server produce SQL-ish results including all of its headers that are required. As such for each XQuery query a single ResultSet is returned with one column (varchar of course) holding the XQuery output. The number of rows is equal to the number of Resources in the XQuery Result. Let me know if you need additional information.
Fabian wrote:
is it of any use to you to know that XML:DB (a Java based XML kind of JDBC driver) is based on JDBC, and that for that I had to make MonetDB/XQuery able to talk with the JDBC driver? I made this JDBC/XQuery 'marriage' by letting the XQuery server produce SQL-ish results including all of its headers that are required. As such for each XQuery query a single ResultSet is returned with one column (varchar of course) holding the XQuery output. The number of rows is equal to the number of Resources in the XQuery Result.
Well, I'm sure a DBI/XQuery 'marriage' is possible too. (After all, there flows some text between client and server - it's not rocket science.) Further, I predict only minor changes are necessary. However, DBI is somewhat SQL biased (i.e. table-oriented) - thus I doubt that we'll celebrate a golden wedding. BTW: I'm not very enthusiastic about the DBI/MIL 'marriage' too. I support it because it was already there. A separate perl module, more in the spirit of MIL, may be more convenient. (Is it true that you plan a MIL successor? It may be wiser to delay my musing until then ...) Steffen
Steffen Goeldner wrote:
Fabian wrote:
is it of any use to you to know that XML:DB (a Java based XML kind of JDBC driver) is based on JDBC, and that for that I had to make MonetDB/XQuery able to talk with the JDBC driver? I made this JDBC/XQuery 'marriage' by letting the XQuery server produce SQL-ish results including all of its headers that are required. As such for each XQuery query a single ResultSet is returned with one column (varchar of course) holding the XQuery output. The number of rows is equal to the number of Resources in the XQuery Result.
Well, I'm sure a DBI/XQuery 'marriage' is possible too. (After all, there flows some text between client and server - it's not rocket science.) Further, I predict only minor changes are necessary. However, DBI is somewhat SQL biased (i.e. table-oriented) - thus I doubt that we'll celebrate a golden wedding. BTW: I'm not very enthusiastic about the DBI/MIL 'marriage' too. I support it because it was already there. A separate perl module, more in the spirit of MIL, may be more convenient. (Is it true that you plan a MIL successor? It may be wiser to delay my musing until then ...) There is (a lot of) work in progress... but could you give a hint towards your ideas of an 'ideal' world? Would you opt for a direct linkage of the kernel routines with a Perl wrapper?
regards, Martin
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-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
Martin Kersten wrote:
Steffen Goeldner wrote:
BTW: I'm not very enthusiastic about the DBI/MIL 'marriage' too. I support it because it was already there. A separate perl module, more in the spirit of MIL, may be more convenient. (Is it true that you plan a MIL successor? It may be wiser to delay my musing until then ...)
There is (a lot of) work in progress...
I'm curious!
but could you give a hint towards your ideas of an 'ideal' world? Would you opt for a direct linkage of the kernel routines with a Perl wrapper?
Yeah, BAT's in perl space would be great (or - even better - n-ary relations). And ideally, we would have location transparency, i.e. we would be able to, say, join a local temporary relation with a remote persistent one. Back to reality though. What I find most annoying with SQL/CLI, ODBC, JDBC, DBI etc. is it's host language integration (or lack thereof). For instance, SQL statements are embedded in strings - I consider this as a low level protocol layer. People try to invent host language counterparts, e.g. Schema::Table->find( key => 'value') It's possible to elaborate this approach somewhat, but you'll encounter difficulties soon. For MIL, I think, the chances are somewhat better (at least for the algebra module). A perlish counterpart could look like: use MonetDB::IL(); my $b = MonetDB::IL->bat('int','int'); $b->insert( 2, 22 ); $b->insert( 1, 11 ); $b->print; $b->sort->print; my $c = $b->slice( 1, 1 ); $c->print; $b->diff( $c )->print; my $d = $b->reverse; $d->print; $d->union( $c )->print; $d->project( 77 )->print; The attached module supports these sketchy trials. Perhaps, eventually, I try to push this approach as far as it can go (and maybe a little beyond ;-) Steffen package MonetDB::IL; sub bat { my $class = shift; MonetDB::IL::BAT->new("new( $_[0], $_[1] )"); } package MonetDB::IL::BAT; use MapiLib(); my $mapi = MapiLib::mapi_connect( (undef) x 5 ) or die 'Cxn failed!'; die MapiLib::mapi_error_str( $mapi ) if MapiLib::mapi_error( $mapi ); my $hdl = MapiLib::mapi_new_handle( $mapi ); my $i = 1; sub _do { my $statement = shift; print "\n>$statement\n"; MapiLib::mapi_query_handle( $hdl,"$statement;"); my $err = MapiLib::mapi_result_error( $hdl ); die $err if $err; die MapiLib::mapi_error_str( $mapi ) if MapiLib::mapi_error( $mapi ); } sub new { my $class = shift; my $statement = shift; my $name = "my_bat_$i"; $i++; _do("var $name := $statement"); bless { Name => $name }, $class; } sub print { my $self = shift; _do("print( $self->{Name} )"); while ( MapiLib::mapi_fetch_row( $hdl ) ) { printf "[ %s %s ]\n", MapiLib::mapi_fetch_field( $hdl, 0 ) , MapiLib::mapi_fetch_field( $hdl, 1 ); } } sub DESTROY { } sub AUTOLOAD { my $self = shift; my $s = $AUTOLOAD; $s =~ s/.*:://; my @p = map { ref $_ ? $_->{Name} : $_ } @_; $s .= '( ' . join(', ', $self->{Name}, @p ) . ' )'; return ref( $self )->new( $s ) if defined wantarray and not wantarray; _do( $s ); } 1;
Steffen Goeldner wrote:
Well, I'm sure a DBI/XQuery 'marriage' is possible too. (After all, there flows some text between client and server - it's not rocket science.) Further, I predict only minor changes are necessary. However, DBI is somewhat SQL biased (i.e. table-oriented) - thus I doubt that we'll celebrate a golden wedding.
I was just trying to point out that XQuery already can give you SQL-ish output, so the only thing you have to do is make sure you don't send the wrong (auto) commands, such as auto-commit, and all of your tabular/resultset based routines should be happy. I mapped XQuery's Results on SQL's ResultSets, and XQuery's Resources on SQL's Rows.
Fabian wrote:
Steffen Goeldner wrote:
Well, I'm sure a DBI/XQuery 'marriage' is possible too. (After all, there flows some text between client and server - it's not rocket science.) Further, I predict only minor changes are necessary. However, DBI is somewhat SQL biased (i.e. table-oriented) - thus I doubt that we'll celebrate a golden wedding.
I was just trying to point out that XQuery already can give you SQL-ish output, so the only thing you have to do is make sure you don't send the wrong (auto) commands, such as auto-commit, and all of your tabular/resultset based routines should be happy. I mapped XQuery's Results on SQL's ResultSets, and XQuery's Resources on SQL's Rows.
Understood. I just removed the restriction for the language parameter in DBD::monetdb. The AutoCommit handler calls 'set auto_commit = ...' only for SQL. The commit()/rollback() methods call commit/rollback for SQL, commit();/abort(); otherwise. It may be better to call the latter only for MIL and nothing otherwise. Opinions? Steffen
participants (4)
-
Fabian -
Martin Kersten -
Peter van der Kamp -
Steffen Goeldner