- developers-list - monetdb.org

[Monetdb-developers] Python DB API
by Arjan Scherpenisse 26 Apr '04

26 Apr '04

I have written some wrapper classes around Sjoerd's SWIG-generated Mapi and MapiLib modules, which serve as a Python DB-API 2.0 compliant database interface to Monet. If youre interested check out http://homepages.cwi.nl/~scherpen/Monet-python-DBAPI.tar.gz Maybe someone even should put this into Monet CVS cheers, -- Arjan Scherpenisse Centrum voor Wiskunde en Informatica, Amsterdam, the Netherlands

1 0

[Monetdb-developers] monetdb as embedded database ??
by Roberto Saccon 26 Apr '04

26 Apr '04

Hi all I would like to know whether it makes sense to use monetdb as database embedded into uerapplication, comparable to Berkeley DB (non-relational) or sqlite (relational). What is the footprint size ? What I have seen so far, the C-Apis only allow access to the DB by sockets. Or am I wrong ?? Does there iexisst a project where monetdb is embedded ? regards Roberto

1 0

[Monetdb-developers] micro CVS HowTo
by Stefan.Manegold＠cwi.nl 25 Apr '04

25 Apr '04

Dear fellow developers, for your convenience, here's a micro CVS HowTo: - initial checkout the head of the main/development branch: cvs -d<user>@cvs.sf.net:/cvsroot/monetdb co -P MonetDB - initial checkout the head of a release branch: cvs -d<user>@cvs.sf.net:/cvsroot/monetdb co -P -rMonetDB_4-3-16 MonetDB - tranforming a check-out main/development branch into a checked-out release branch: cvs up -dP -rMonetDB_4-3-16 - tranforming a check-out release branch into a checked-out main/development branch: cvs up -dP -A - updating a check-out main/development or release branch: cvs up -dP - checking, whether your current check-out it a main/development or release branch: cat CVS/Tag main/development branch: CVS/Tag does not exist release branch: CVS/Tag contains branch name/tag - checking you own changes (preferably prior to checkin): cvs diff Stefan -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

1 0

[Monetdb-developers] MonetDB Testing & Status-Alert
by Stefan.Manegold＠cwi.nl 25 Apr '04

25 Apr '04

Dear fellow developers, let me first apologize for the fact that I haven't been able to maintain the nightly testing as usual while I was abroad the week before last week (Sa, April 10 - Su, April 18). During this time, problems with SourceForge (that are beyond our control) as well as problem with the Windows testing (that are somehow under our control, see below), caused the automatic testing to fail, and hence could not provide you with the usual feedback about your checkins. Furthermore, I also have to apologize, that I did not manage to get the testing working again, during last week, while being back at work. Well, at least, the SF problems seems to be gone, again. The windows problem is still there: recent changes in the release branch(!) of MonetDB seem to cause "Application Errors" (aka SegFaults) on Windows, and my non-interactive test-environment is unfortunately not able to press the "Ok" button on the respective pop-up window... Well, thanks to some hint from our new friends at SAP, I (hopefully) just managed to avoid these pop-up windows on our Windows test machine. Hence, testing should hang there anymore, even in case of "Application Errors". These problem solved, I had a short(!) look at today's Stable testweb, at what I saw did *scare* me a bit: ! The current "stable" version of MonetDB (4.3.16) seems to be pretty broken ! While many difference are "only" due to "harmless" changes in the output (e.g., caused by changes in the behaviour/output of commands such as "atoms()"), there are some changes that indicate that "join" is broken ! Well, I guess, I'll have to spend tomorrow or Monday on looking at the details and sorting out, what did go wrong with your checkins to the (no longer) "stable" release branch... Admittedly, I have to blame myself, again: Not only did I not keep the automatic testing properly running during the last two week, but I also forgot to give any guidelines, how to handle checkins to the "stable" branch after the release had been made... (No, I don't metion anymore, that Mtest might be run by hand on your favorite development platform, at least before checking-in "bug-fixes" to the "stable" branch...) To see it positively, this observation confirms that we do not "waste" any time or money by having one person spending a major part of his/her (official) working hours on "quality control" --- I just forgot to find/name a stand-in while being abroad myself...). Good night, Stefan -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

1 2

[Monetdb-developers] Mapi blocked mode multi query consideration
by Fabian 22 Apr '04

22 Apr '04

Mapi has two modes, which I refer to as line mode and block mode. The main plus for the client when using the block mode variant is that multi-line queries can be sent directly to the server without any parsing. The line mode variant, on the other hand, separates lines by newline characters, so multiline queries are not possible; one has to replace all newlines by spaces when not inside a string, otherwise by \n. (this requires some parsing of the query before sending) Now the problem I'm dealing with is as follows: If I send a multiline query using blockmode to the server, and that query is syntactically incorrect (according to the server), the server returns that same multiline query. In the result mode, however, newlines are treated as row delimiters. The effect of this, is that only the first row of the query sent is visible, which most of the time does not contain the error. For example, suppose the following query is sent: SELECT * FROM "foobar"; where the table foobar does not exist in the catalog, then the error message will be: !ERROR parse error at token (257) in statement: select * from "foobar" which due to row-style parsing will only result in the error message with query 'select *'. The question here is actually, who is doing what wrong? Any thoughts on this?

2 2

Re: [Monetdb-developers] Python + SQL
by Arjan Scherpenisse 22 Apr '04

22 Apr '04

Martin, I have fixed the Mapi.py thanks to Niels' tips. The result strings still need parsing ofcourse. I could write my own parsing or write wrappers for the existing Mapi.h API. I am willing to implement a Python database wrapper according to the Python Database API specs (http://www.python.org/peps/pep-0249.html). Maybe we can talk about this tomorrow with Peter, and how something like this can fit into my graduation work ;) regards, Arjan Martin Kersten wrote: > Arjan, > > It supprises me, because the Mapi protocol does not constrain the > language. I noticed, though, that MapiClient.py is currently hardwired > for mil indeed. It seems that Sjoerd (the Python expert) can help > you (and make MapiClient.py a little better?) > > The main question to decide upon is the functionality required. > Using ODBC would allow your application also to run on other DBMSs > From the perspective of re-use that is a nice property. Ofcourse, > the application builder has to spent more energy to prepare for this. > Using the ODBC layer of Sjoerd would be a good exercise to challenge > its current functionality. Help is close at hand to make it bearable. > > Perhaps an issue to discuss with Peter (and me). > > regards, Martin > > Arjan Scherpenisse wrote: > >> Hello, >> >> can someone point me to a simple way of using the SQL frontend from >> within Python? The default interface (Mapi.py) does only allow the MIL >> language, as far as I can see. >> >> In the past I did it by using the ODBC module, but that was very >> tiresome. Is there a better way? >> >> cheers, Arjan >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: IBM Linux Tutorials >> Free Linux tutorial presented by Daniel Robbins, President and CEO of >> GenToo technologies. Learn everything from fundamentals to system >> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >> _______________________________________________ >> Monetdb-developers mailing list >> Monetdb-developers(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/monetdb-developers > > > -- Arjan Scherpenisse Centrum voor Wiskunde en Informatica, Amsterdam, the Netherlands

2 2

[Monetdb-developers] Python + SQL
by Arjan Scherpenisse 20 Apr '04

20 Apr '04

Hello, can someone point me to a simple way of using the SQL frontend from within Python? The default interface (Mapi.py) does only allow the MIL language, as far as I can see. In the past I did it by using the ODBC module, but that was very tiresome. Is there a better way? cheers, Arjan

1 0

[Monetdb-developers] timestamp
by Arjan Scherpenisse 07 Apr '04

07 Apr '04

Hi list, I am importing some tab-separated dump data in which a field is a timestamp, formatted ala "2003-11-26 10:36:53". After importing (through make_persistent/load_data), the two timestamp BATs show up as: [ "profile_track_history_date", "oid", nil, 4516232, 0, "clean", "disk", "pers", 0, 1 ] [ "profile_track_history_serverdate", "oid", nil, 4516232, 0, "clean", "disk", "pers", 0, 1 ] (having a 'nil' tail-type). I guess this is a minor bug; because the BATs are filled with timestamps properly. regards, Arjan

3 5

[Monetdb-developers] Security & usability
by Fabian 04 Apr '04

04 Apr '04

After the checkin by Martin (about giving -u and -P default values on MapiClient), I had to laugh loudly for a minute (or two) after which I had to frown, thinking about the security aspect of this change. Not that it changes much, but being a little minded towards a better situation is not a bad thing IMHO. (Also for the reputation of monet by itself for the outside world) Because I regularly get tired of typing long command line arguments as well, I propose the following solution, which might fit all kinds of tastes. What if we would store some preferences we have in a file ~/.monetdb or something which can be shared by various applications, like MapiClient, JdbcClient, Mserver itself, and maybe any more... The file would be simply a properties file containing something like username=monetdb password=monetdb language=sql startscript=~/monetdb/start_sql which would instruct MapiClient to use sql language with username + pass monetdb and tell Mserver when it starts to load the script ~/monetdb/start_sql so I for instance would not have to type 'module(sql_server);' anymore. Of course command line options override these defaults in this .monetdb file. It is up to the user to chmod it to 600. How about this idea?

3 3

[Monetdb-developers] PHP interface
by Marcin Zukowski 03 Apr '04

03 Apr '04

Hello Monet-hackers, Recently I implemented a PHP Monet interface. Documentation is here: file://localhost/ufs/marcin/utils/phpdoc/html/ref.monetdb.html (accessible from CWI). If anyone of you is interested and would like to play with it, I would be grateful for any comments. Regards, marcin -- : Marcin Zukowski < marcin(a)cwi.nl || eru(a)mimuw.edu.pl > : All true wisdom is found in signatures

1 0