- developers-list - monetdb.org

[Monetdb-developers] Crash leaves me unable to start mserver
by Joseph.Baird＠cox.com 09 Oct '06

09 Oct '06

After loading several million records via odbc, the server is suddenly unresponsive but can be restarted. When using jdbc, the server crashes, again after several million records, but cannot be restarted. Performance and usability are impressive with a million records or so but I cannot seem to load more than that without consistent problems. Is there any way to make the server - and ideally the database - usable again? Thank you in advance, Joe Baird

2 1

Re: [Monetdb-developers] Monetdb-developers Digest, Vol 5, Issue 6
by p.a.boncz 06 Oct '06

06 Oct '06

Hi all, > In PROC rpc_client() (runtime/xrpc.mx), I had changed > ws_addcoll(ws, ... > to > ws_opencoll(ws_id(ws), ... it should we ws_opencoll(wsid, ...) You have that, because in the query context we always have both variable 'ws' and 'wsid'. ws_id(ws) should be called once, it asks for a unique oid. The combination of (id,int(ws)) is squeezed into a lng, and that is wsid. As for doc_tbl(), what would work is to change its parameter to wsid; one can always get the ws with ws := ws_bat(wsid), this is done now in numerous places in pf_support.mx. Your conclusions (1), (2) and (3) are all correct. But, Jan's suggestion to store the wsid inside the ws can also work. However, I deem it very awkward to introduce a new BAT in the ws just to retain a number. Other suggestions are to rename the ws-bat to some unique key, and then we can use that name as transaction key (=wsid). We would change the wsid type then from lng to str. Another idea is to set the head-seqbase of the ws-bat to an oid. I think the ws is accessed with fetch() only, which disregards any seqbase. Note that internally in pathfinder.mx there are a number of functions that just pass around an artificial wsid, and in fact a ws does not exist at all (this is the MIL document management interface e.g. shred_doc), so a number of (internal) functions in pathfinder.mx will have to stay using a wsid in their signature. They do not need a ws-bat. But the exported functions ws_opencoll and ws_opendoc could indeed just use a ws as they did before. I will not have time for this until next week, so if anyone feels like adventurous, he may try. Peter -- | 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 | ------------------------------ Message: 2 Date: Fri, 6 Oct 2006 12:43:21 +0200 From: Stefan Manegold <Stefan.Manegold(a)cwi.nl> Subject: Re: [Monetdb-developers] The new "ws-API", Algebra & XRpc (& PFtijah) To: Monetdb-developers(a)lists.sourceforge.net Message-ID: <20061006104321.GA2821(a)corona.ins.cwi.nl> Content-Type: text/plain; charset=us-ascii On Thu, Oct 05, 2006 at 11:03:09AM +0200, Stefan Manegold wrote: > Dear Peter, dear fellow PF & MXQ developers, [...] > In cases of XRpc & Algebra, there are still places were wsid := ws_id(ws) is > IMHO called in the wrong location: > > XRpc: > In PROC rpc_client() (runtime/xrpc.mx), I had changed > ws_addcoll(ws, ... > to > ws_opencoll(ws_id(ws), ... > While this seems to worg for now with read-only documents (i.e., in the > absense of updates and concurrency), it is IMHO incorrect in general. > Rather, rpc_client should receive wsid as argument instead of ws; > if necessary, ws can then be derived via ws := ws_bat(wsid). I just changed the signatures of doLoopLiftedRPC() & rpc_client() to receive lng wsid instead of BAT ws, BAT ws is the locally derived via ws := ws_bat(wsid); All XRpc tests seem to work fine. 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 | ------------------------------ Message: 3 Date: Fri, 06 Oct 2006 14:39:19 +0200 From: Jan Rittinger <rittinge(a)in.tum.de> Subject: Re: [Monetdb-developers] The new "ws-API", Algebra & XRpc (& PFtijah) To: Monetdb-developers(a)lists.sourceforge.net Message-ID: <45264E77.3060201(a)in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed If this wsid is a concept that is strictly necessary for the update support (and nobody except me thinks that this bit shifting might be not the nicest solution) we could also think about getting rid of the ws and replacing it with the wsid. I just do not like the fact that there are two variables underway that have some side effects on each other. So a fourth proposal (d) would be to replace the occurrences of ws by wsid. This would mean that *all* document accesses would have to include another indirection (even all path steps). On 10/05/2006 11:03 AM, Stefan Manegold wrote with possible deletions: > Dear Peter, dear fellow PF & MXQ developers, > > I'm not sure, whether I do understand the new "ws-API" correctly, and would > be grateful if someone of you could enlighten me. > > First, here's how far I get so far (please correct me if/where I'm wrong!), > followed by concrete open questions. > > For transaction support, Peter introduced a new wsid that uniquely > identifies (a reference to?) a ws, which is required for conflict detection > (as far as I understand). > > A wsid is to be generated from/for a ws by calling wsid := ws_id(ws); > however, this generated a new unique id each time is called (two calls on > the same ws yield two different ids, right?), hence, wsid := ws_id(ws) > should immediately follow ws := ws_create() . > > For the inverse, there is ws := ws_bat(wsid) that return the ws identified > by wsid; obviously, this function yield the same result each time it's > called with the same wsid. > > Since some functionality required to to the wsid instead of "only" the ws, > Peter had changes the signatures/API of some runtime PROCs. As far as I see > right now, these are mainly (only?) > ws_doc(ws, ... -> ws_opendoc(wsid, ... > ws_addcoll(ws, ... -> ws_opencoll(wsid, ... > ws_destroy(int(ws)) -> ws_destroy(wsid) > > I finished these changes by simply running the folloing one-liners: > > find * -type f | xargs grep -l 'var ws := ws_create();' | xargs perl -i -p -e 's|(var ws := ws_create;)|$1 var wsid := ws_id(ws);|' > find * -type f | xargs grep -l 'ws_doc(ws,' | xargs perl -i -p -e 's|ws_doc$ws,|ws_opendoc(wsid,|' > find * -type f | xargs grep -l 'ws_destroy(int(ws))' | xargs perl -i -p -e 's|ws_destroy\(int\(ws$\)|ws_destroy(wsid)|' > find * -type f | xargs grep -l 'ws_addcoll(ws,' | xargs perl -i -p -e 's|ws_addcoll\(ws,|ws_opencoll(wsid,|' > find * -type f | xargs grep -l 'ws_addcoll' | xargs perl -i -p -e 's|ws_addcoll|ws_opencoll|' > > > While this seemed to have been enough to fix all .milS tests and (most of) > the milprint_summer functionallity, there are two open issues left: > the Algebra version, XRpc & PFtijah. > > To be honest, I haven't looked at PFtijah, yet; some help by the respective > experst would be appreciated. > > > In cases of XRpc & Algebra, there are still places were wsid := ws_id(ws) is > IMHO called in the wrong location: > > XRpc: > In PROC rpc_client() (runtime/xrpc.mx), I had changed > ws_addcoll(ws, ... > to > ws_opencoll(ws_id(ws), ... > While this seems to worg for now with read-only documents (i.e., in the > absense of updates and concurrency), it is IMHO incorrect in general. > Rather, rpc_client should receive wsid as argument instead of ws; > if necessary, ws can then be derived via ws := ws_bat(wsid). > > Algebra: > in PROC doc_tbl() (runtime/pf_support.mx), I had changed > var r := ws_doc(ws, item); > into > var wsid := ws_id(ws); > var r := ws_opendoc(wsid, item); > Same story as above. > However, doc_tbl return ws also in its result BAT-of-BATs, as far as I > understand mainly for "canonical API" reasons. > Obviously, it is not possible to replace BAT ws by lng wsid, here... > > > Leaving the latter problem aside for the moment, the following could (have) > work(ed) as a general rule, and we should check and change the codebase > accordingly: > > 1) wsid := ws_id(ws) must only be called immediately after ws := ws_create() > > 2) all functions/PROCs that recursively (i.e., including all transitively > called functions/PROCs) require wsid instead of or inaddition to ws should > be modified in that the receive wsid instead of ws as an argument; > ws can then locally be derived via ws := ws_bat(wsid) if/where necessary. > > 3) all functions/PROCs that recursively (i.e., including all transitively > called functions/PROCs) "never" (at least not yet) require wsid, but are > fine with ws can stay unchanged, i.e., getting (only) ws as argument. > Obviously, wherever these functions need to maintain a signature/API > aligned with those that fall under point 2) above, we should also change > these functions as described above with 2). > > > As indicated above, this does not work for doc_tbl and its companion PROCs > in runtime/pf_support.mx that make-up the interface between the Algebra > version of the compiler and the runtime. > I assume the respective canonical API could be changed in that the > respective PROC get wsid instead of (or in addition to?) ws as arguments. > However, we cannot easily change the API to return wsid (lng) instead of ws > (BAT) in the result BAT-of-BATs. Here, I see three solutions --- the last > one actually comes from JanR: > > a) Is ws/wsid indeed required in the result? > If not, we could simply discard it. > > b) Wrap wsid temprarly into a ("fake") [void,lng] BAT containing only one > (nil,wsid) BUN. > (Ugly!) > > c) (JanR) Put the wsid inside ws --- basically as a ("fake") BAT [void,lng]. > Kind of the "encapsulated" solution --- not only for the algebra-runtime > interface! > Consequently, we should have ws_create() call ws_id(ws) internally and > stored the result in ws (this could save the seemingly "redundant" > ws := ws_create(); wsid := ws_id(ws); sequence), and all (most, except at > least ws_destroy()) signatures/API could be kept / re-unified to pass > (only) ws (now including wsid) instead of wsid as argument. > > There seems to be one problem, so, if I understand Peter's comment > correctly: > " > - ws-IDs are now lng-s (combination of *unique* ID and bat-ID) such IDs > are meaningful also after the query is done (and ws-bat deallocated). > ^1^1^1^1^1^1^1^1^1^1^1^1^1^1 ^2^2^2^2^2^2^2^2^2^2^2 > this is needed for trans mgmt. > All meta-bats witha ws-id field now hold lng instead of int. > " > > In other words, (^2) wsid needs to be available also if ws is gone. > I'm not sure, though, whether is has to be available in the global wsid > variable (i.e., inside/during the query), or (only) in some meta-bats > outside (and hence after) the query (-context) (as suggested by ^1). > > > Peter, > > could you please enlighten me/us, here? > > > In case "only" (^1) is required, the "encapsulated" solution seems indeed > to be suitable for all code. > Otherwise, is would at least be a local solution for the algebra-runtime > interface (in case (a) & (b0 are no option), but bears the burden of > maintaining consistency between the global wsid variable and the wsid stored > inside the ws. > > > I hope, this email and any reactions to it help to clearify the current > situation, rather than to blur it even more ... > > Stefan > > -- Jan Rittinger Database Systems Technische Universit?t M?nchen (Germany) http://www-db.in.tum.de/~rittinge/ ------------------------------ Message: 4 Date: Fri, 6 Oct 2006 15:08:00 +0200 From: Stefan Manegold <Stefan.Manegold(a)cwi.nl> Subject: Re: [Monetdb-developers] The new "ws-API", Algebra & XRpc (& PFtijah) To: Jan Rittinger <rittinge(a)in.tum.de> Cc: Monetdb-developers(a)lists.sourceforge.net Message-ID: <20061006130800.GB5598(a)corona.ins.cwi.nl> Content-Type: text/plain; charset=us-ascii On Fri, Oct 06, 2006 at 02:39:19PM +0200, Jan Rittinger wrote: > If this wsid is a concept that is strictly necessary for the update > support (and nobody except me thinks that this bit shifting might be not > the nicest solution) we could also think about getting rid of the ws and > replacing it with the wsid. I just do not like the fact that there are > two variables underway that have some side effects on each other. To be honest, I'm still in the process of analyzing trying to understand, what all the flavors, pros, cons, and ideas behind having/using wsid are; hence, I cannot tell, whether it is "strictly necessary" or not. As far as I understand so far, the basic idea behind the "bit shifting" is merely to store both the id of (and hence reference to) BAT ws as well as a unique identifier --- that is still valid after a query/transaction (and hence cannot simply be the ws BAT id, which might be re-used for a subsequent query/transaction) --- in one single atomic value. Further, I agree, that having two related variables that need to be kept in sync and treated accordingly is not very handy for maintenance --- my guess is, that the current situation resulted from lack of time and fear to implement (something like) your (d) proposal; which I agree is "nicer" & "cleaner", but requires quite a lot of possibly error-prone code changes --- nevertheless, I might give it a try during the weekend ... Stefan > So a fourth proposal (d) would be to replace the occurrences of ws by > wsid. This would mean that *all* document accesses would have to include > another indirection (even all path steps). -- | 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 | ------------------------------ Message: 5 Date: Fri, 6 Oct 2006 15:42:02 +0200 From: Stefan Manegold <Stefan.Manegold(a)cwi.nl> Subject: Re: [Monetdb-developers] The new "ws-API", Algebra & XRpc (& PFtijah) To: Monetdb-developers(a)lists.sourceforge.net Cc: Jan Rittinger <rittinge(a)in.tum.de> Message-ID: <20061006134202.GA6958(a)corona.ins.cwi.nl> Content-Type: text/plain; charset=us-ascii On Fri, Oct 06, 2006 at 03:08:00PM +0200, Stefan Manegold wrote: > On Fri, Oct 06, 2006 at 02:39:19PM +0200, Jan Rittinger wrote: > > If this wsid is a concept that is strictly necessary for the update > > support (and nobody except me thinks that this bit shifting might be not > > the nicest solution) we could also think about getting rid of the ws and > > replacing it with the wsid. I just do not like the fact that there are > > two variables underway that have some side effects on each other. > > To be honest, I'm still in the process of analyzing trying to understand, > what all the flavors, pros, cons, and ideas behind having/using wsid are; > hence, I cannot tell, whether it is "strictly necessary" or not. > > As far as I understand so far, the basic idea behind the "bit shifting" is > merely to store both the id of (and hence reference to) BAT ws as well as a > unique identifier --- that is still valid after a query/transaction (and hence > cannot simply be the ws BAT id, which might be re-used for a subsequent > query/transaction) --- in one single atomic value. > > Further, I agree, that having two related variables that need to be kept in > sync and treated accordingly is not very handy for maintenance --- my guess > is, that the current situation resulted from lack of time and fear to > implement (something like) your (d) proposal; which I agree is "nicer" & > "cleaner", but requires quite a lot of possibly error-prone code changes --- > nevertheless, I might give it a try during the weekend ... > > Stefan > > > So a fourth proposal (d) would be to replace the occurrences of ws by > > wsid. This would mean that *all* document accesses would have to include > > another indirection (even all path steps). Well, I just realize that this actually only helps to save us from having function interfaces that expect/use either ws or wsid or both --- it does not help to get rid of the global ws variable: to exist throught the whole query, the ws BAT must either be a global variable or be persistent --- the latter is not possible, since ws is a BAT-of-BATs, and those cannot be persistent... ... I just recall, that we have something like "session" BATs --- I'll check whether that's an option (any help/hint is of course welcome ...) 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 | ------------------------------ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ------------------------------ _______________________________________________ Monetdb-developers mailing list Monetdb-developers(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers End of Monetdb-developers Digest, Vol 5, Issue 6 ************************************************

2 3

[Monetdb-developers] The new "ws-API", Algebra & XRpc (& PFtijah)
by Stefan Manegold 06 Oct '06

06 Oct '06

Dear Peter, dear fellow PF & MXQ developers, I'm not sure, whether I do understand the new "ws-API" correctly, and would be grateful if someone of you could enlighten me. First, here's how far I get so far (please correct me if/where I'm wrong!), followed by concrete open questions. For transaction support, Peter introduced a new wsid that uniquely identifies (a reference to?) a ws, which is required for conflict detection (as far as I understand). A wsid is to be generated from/for a ws by calling wsid := ws_id(ws); however, this generated a new unique id each time is called (two calls on the same ws yield two different ids, right?), hence, wsid := ws_id(ws) should immediately follow ws := ws_create() . For the inverse, there is ws := ws_bat(wsid) that return the ws identified by wsid; obviously, this function yield the same result each time it's called with the same wsid. Since some functionality required to to the wsid instead of "only" the ws, Peter had changes the signatures/API of some runtime PROCs. As far as I see right now, these are mainly (only?) ws_doc(ws, ... -> ws_opendoc(wsid, ... ws_addcoll(ws, ... -> ws_opencoll(wsid, ... ws_destroy(int(ws)) -> ws_destroy(wsid) I finished these changes by simply running the folloing one-liners: find * -type f | xargs grep -l 'var ws := ws_create();' | xargs perl -i -p -e 's|(var ws := ws_create;)|$1 var wsid := ws_id(ws);|' find * -type f | xargs grep -l 'ws_doc(ws,' | xargs perl -i -p -e 's|ws_doc$ws,|ws_opendoc(wsid,|' find * -type f | xargs grep -l 'ws_destroy(int(ws))' | xargs perl -i -p -e 's|ws_destroy\(int\(ws$\)|ws_destroy(wsid)|' find * -type f | xargs grep -l 'ws_addcoll(ws,' | xargs perl -i -p -e 's|ws_addcoll\(ws,|ws_opencoll(wsid,|' find * -type f | xargs grep -l 'ws_addcoll' | xargs perl -i -p -e 's|ws_addcoll|ws_opencoll|' While this seemed to have been enough to fix all .milS tests and (most of) the milprint_summer functionallity, there are two open issues left: the Algebra version, XRpc & PFtijah. To be honest, I haven't looked at PFtijah, yet; some help by the respective experst would be appreciated. In cases of XRpc & Algebra, there are still places were wsid := ws_id(ws) is IMHO called in the wrong location: XRpc: In PROC rpc_client() (runtime/xrpc.mx), I had changed ws_addcoll(ws, ... to ws_opencoll(ws_id(ws), ... While this seems to worg for now with read-only documents (i.e., in the absense of updates and concurrency), it is IMHO incorrect in general. Rather, rpc_client should receive wsid as argument instead of ws; if necessary, ws can then be derived via ws := ws_bat(wsid). Algebra: in PROC doc_tbl() (runtime/pf_support.mx), I had changed var r := ws_doc(ws, item); into var wsid := ws_id(ws); var r := ws_opendoc(wsid, item); Same story as above. However, doc_tbl return ws also in its result BAT-of-BATs, as far as I understand mainly for "canonical API" reasons. Obviously, it is not possible to replace BAT ws by lng wsid, here... Leaving the latter problem aside for the moment, the following could (have) work(ed) as a general rule, and we should check and change the codebase accordingly: 1) wsid := ws_id(ws) must only be called immediately after ws := ws_create() 2) all functions/PROCs that recursively (i.e., including all transitively called functions/PROCs) require wsid instead of or inaddition to ws should be modified in that the receive wsid instead of ws as an argument; ws can then locally be derived via ws := ws_bat(wsid) if/where necessary. 3) all functions/PROCs that recursively (i.e., including all transitively called functions/PROCs) "never" (at least not yet) require wsid, but are fine with ws can stay unchanged, i.e., getting (only) ws as argument. Obviously, wherever these functions need to maintain a signature/API aligned with those that fall under point 2) above, we should also change these functions as described above with 2). As indicated above, this does not work for doc_tbl and its companion PROCs in runtime/pf_support.mx that make-up the interface between the Algebra version of the compiler and the runtime. I assume the respective canonical API could be changed in that the respective PROC get wsid instead of (or in addition to?) ws as arguments. However, we cannot easily change the API to return wsid (lng) instead of ws (BAT) in the result BAT-of-BATs. Here, I see three solutions --- the last one actually comes from JanR: a) Is ws/wsid indeed required in the result? If not, we could simply discard it. b) Wrap wsid temprarly into a ("fake") [void,lng] BAT containing only one (nil,wsid) BUN. (Ugly!) c) (JanR) Put the wsid inside ws --- basically as a ("fake") BAT [void,lng]. Kind of the "encapsulated" solution --- not only for the algebra-runtime interface! Consequently, we should have ws_create() call ws_id(ws) internally and stored the result in ws (this could save the seemingly "redundant" ws := ws_create(); wsid := ws_id(ws); sequence), and all (most, except at least ws_destroy()) signatures/API could be kept / re-unified to pass (only) ws (now including wsid) instead of wsid as argument. There seems to be one problem, so, if I understand Peter's comment correctly: " - ws-IDs are now lng-s (combination of *unique* ID and bat-ID) such IDs are meaningful also after the query is done (and ws-bat deallocated). ^1^1^1^1^1^1^1^1^1^1^1^1^1^1 ^2^2^2^2^2^2^2^2^2^2^2 this is needed for trans mgmt. All meta-bats witha ws-id field now hold lng instead of int. " In other words, (^2) wsid needs to be available also if ws is gone. I'm not sure, though, whether is has to be available in the global wsid variable (i.e., inside/during the query), or (only) in some meta-bats outside (and hence after) the query (-context) (as suggested by ^1). Peter, could you please enlighten me/us, here? In case "only" (^1) is required, the "encapsulated" solution seems indeed to be suitable for all code. Otherwise, is would at least be a local solution for the algebra-runtime interface (in case (a) & (b0 are no option), but bears the burden of maintaining consistency between the global wsid variable and the wsid stored inside the ws. I hope, this email and any reactions to it help to clearify the current situation, rather than to blur it even more ... 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 |

2 4

[Monetdb-developers] bolts damaged
by server RTz 04 Oct '06

04 Oct '06

attack applies contact area ordinary wrenches Kroc. HSW Fact Day: paintball markers Foresters Boards Blogs Segments SNAP High Candy Spiked same Guarana fuels amazing BAWLS drink Brown customers saying... Copyright Rights Reserved Statement Company Music.com Reviews Videos support. Resources Getting v. Edition. In earlier releases used similar OS v. Edition. In earlier releases used similar date: Copyright Rights Reserved Statement Company Music.com Reviews Videos InNew User Connect S.com Market Forums Boards Blogs Segments SNAP Next Gaming PRO SAP Oracle Music Palm BREW Cross iMode Windows UIQ Knowledge Known Issues FAQs Tips eUpdate archive Platforms Military Physical drives. gigs Ionut Ambrosie winners meet Monitor home Travel Consumer Products Bawls Mints High Candy

1 0

[Monetdb-developers] Error compiling MEL w/ flex 2.5.33 & bison 2.3
by Stefan Manegold 03 Oct '06

03 Oct '06

On Mon, Oct 02, 2006 at 12:47:39PM +0200, Niels Nes wrote: > On Mon, Oct 02, 2006 at 12:32:22PM +0200, Riham wrote: > > Hi, > > > > I am a new PhD student at the University of Twente. I am working with > > Dr. Maurice van Keulen on Optimizing Pathfinder queries. I was > > installing Monet on my new linux system and I got the following error: > > > > =========================================================================== > > kader@netloosewi840:~/home/MonetDB_XQuery_CVS/build/buildtools> make > > cd > > ""/local/kader/home/MonetDB_XQuery_CVS/build/buildtools/../../src/buildtools"/autogen" > > && python setup.py build > > running build > > running build_py > > running build_scripts > > cd _MX && make MAKE=make all > > make[1]: Entering directory > > `/local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MX' > > make all-am > > make[2]: Entering directory > > `/local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MX' > > make[2]: Nothing to be done for `all-am'. > > make[2]: Leaving directory > > `/local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MX' > > make[1]: Leaving directory > > `/local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MX' > > cd _MEL && make MAKE=make all > > make[1]: Entering directory > > `/local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MEL' > > make all-am > > make[2]: Entering directory > > `/local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MEL' > > g++ -g -o mel any_arg.o atom_arg.o atom.o atomops.o bat_arg.o > > builtin.o command.o debug.o depend.o dependency.o epilogue.o FileInfo.o > > glue.o html.o iterator.o link.o ListIterator.o mel.o mel.tab.o mel.yy.o > > mil.o module.o object.o operator.o ops.o prelude.o proto.o symbol.o > > symtable.o type_arg.o use.o var_arg.o > > mel.tab.o: In function `semerror()': > > /local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MEL/mel.yy:471: > > undefined reference to `yylineno' > > /local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MEL/mel.yy:472: > > undefined reference to `yylineno' > > mel.tab.o: In function `yyparse()': > > /local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MEL/mel.yy:59: > > undefined reference to `yylineno' > > /local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MEL/mel.yy:67: > > undefined reference to `yylineno' > > /local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MEL/mel.yy:131: > > undefined reference to `yylineno' > > mel.yy.o:/local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MEL/mel.ll:253: > > more undefined references to `yylineno' follow > > collect2: ld returned 1 exit status > > make[2]: *** [mel] Error 1 > > make[2]: Leaving directory > > `/local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MEL' > > make[1]: *** [all] Error 2 > > make[1]: Leaving directory > > `/local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MEL' > > make: *** [all] Error 2 > > =========================================================================== > > > > The flex and bison versions I have are 2.5.33 and 2.3 respectively. > > I was advised by Jan Flokstra to report the error to you. I hope you > > have sufficient information to know the origin of the problem, if not > > please let me know. > > > > Thank you for your help, > > Riham Abdel Kader. > > As of flex 2.5.31 the yylineno was defined by flex. Normaly we define > it our selfs. > > You could try to patch the following line from mel.mx > > #if !defined(YY_FLEX_SUBMINOR_VERSION) || YY_FLEX_SUBMINOR_VERSION < 5 > /* flex 2.5.31 declares yylineno. I don't know which other versions > do as well. */ > int yylineno; > #endif > > Simply removed the #if/#endif should work. A better solution is to know > which range between 2.5.6 and 2.5.31/32 have a yylineno defined. And > fix the second part of the #ifdef. > > Niels Niels, Riham, I haven't analysed the problem any further, yet, but I think it might also be related to bison 2.3 or the combination of bison 2.3 and flex 2.5.33. In out nightly testing pool (cf., http://monetdb.cwi.nl/Development/TestWeb/) we use flex 2.5.4 & flex 2.5.33 and bison 1.875, 2.0, 2.1, 2.2, and everything works fine. We don't use bison 2.3, yet ... Riham, which linux distribution (name & version) are you using? Does Niels' patch work for you? 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 |

4 11

Re: [Monetdb-developers] Monetdb-developers Digest, Vol 4, Issue 13
by p.a.boncz 26 Sep '06

26 Sep '06

Hi Jens, I read your recursion proposal, but I do not really understand the need or goal for such a syntax extension: - is't the default XQuery function recursion more powerful? - why not confine oneself to have an *internal* algebraic closure operator, if that is such a useful abstraction? Nor do I understand the need for the focus on nodes and set fixpoint semantics. If the result expression is a sequence of nodes you may define this to be duplicate-free and in document order, but it is less obvious why atomic sequences should be treated like that. Order is a first-class citizen in XQuery, and atomic types are also first-class. And what about element construction? Isn't it obvious given the recursive nature of XML that people may want to build XML documents with recursion -- so the choice to union all results always is limiting. I can imagine that *some* XQuery recursion patterns could be translated to this fixpoint operator. Tail recursion is the big "success story" here (given your node-union fixpoint semantics it will actually only be possible in rare cases). However, given the fact that XQuery has for-loops, it is quite unlikely in the first place that in the real world people will use tail-recursion for iteration (this may distinguish XQuery from "purer" functional languages). I conclude that this extension per-se does not help in translating recursion in XQuery for the algebra backend at all (nor is it its goal), rather places a second recursive vehicle beside it. I am completely puzzled to hear such proposals from the usually XQuery-standard-respecting community in Garching. Finally, what exactly is "hacky" about the milprint_summer recursion approach? Maybe you mean with "hacky" that it does not try to eliminate recursion, and thus only works if the target language offers recursion. The reality is that only trivial recursion patterns can be eliminated, so this limitation will apply always. And you may forget, that a lot of recursion in milprint_summer *is* eliminated, as all calls inside a for-loop are reduced to one thanks to "loop-lifting" (maybe we could even "sell" this idea in the FP community). So actually it surely is not as primitive/hacky as the implementation of recursion in say Galax. Defining myself as an engineer, I am aware of the limitations of my knowledge and understanding of such formal issues. ready to be educated.. Peter -----Original Message----- From: monetdb-developers-bounces(a)lists.sourceforge.net [mailto:monetdb-developers-bounces@lists.sourceforge.net] On Behalf Of monetdb-developers-request(a)lists.sourceforge.net Sent: Saturday, September 23, 2006 12:14 AM To: monetdb-developers(a)lists.sourceforge.net Subject: Monetdb-developers Digest, Vol 4, Issue 13 Send Monetdb-developers mailing list submissions to monetdb-developers(a)lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/monetdb-developers or, via email, send a message with subject or body 'help' to monetdb-developers-request(a)lists.sourceforge.net You can reach the person managing the list at monetdb-developers-owner(a)lists.sourceforge.net When replying, please edit your Subject line so it is more specific than "Re: Contents of Monetdb-developers digest..." Today's Topics: 1. Upcoming feature: Recursion in Pathfinder (algebra) (Jens Teubner) 2. configure & *_config.h include files (Stefan Manegold) 3. Re: configure & *_config.h include files (Stefan Manegold) 4. Error with the Java Client (Jim Foley) 5. Re: Error with the Java Client (Fabian Groffen) ---------------------------------------------------------------------- Message: 1 Date: Fri, 22 Sep 2006 14:11:03 +0200 From: Jens Teubner <jens.teubner(a)in.tum.de> Subject: [Monetdb-developers] Upcoming feature: Recursion in Pathfinder (algebra) To: monetdb-developers(a)lists.sourceforge.net Cc: Loredana Afanasiev <lafanasi(a)science.uva.nl> Message-ID: <20060922121103.GF11762(a)notekemper14.informatik.tu-muenchen.de> Content-Type: text/plain; charset=us-ascii Hi all, this is to keep you informed what we are currently working on in Munich. Pathfinder's purely relational approach so far cannot handle *recursion* in XQuery expression in a sensible way (recursion in the W3C XQuery language is possible by means of user-defined recursive function). The milprint_summer branch includes some hacky implementation (with help of MIL PROCs) that provides recursion nevertheless. Together with people from UVA (Loredana Afanasiev in particular), we are currently working on support for recursion in an algebraic manner. A generic handling of recursion seems quite difficult. The W3C XQuery language syntax does not pose any restrictions on the style of recursion that can be described. The common approaches to deal with recursion in relational systems, in contrast, cannot cope with all these variants of recursion. A second problem is that the kind of recursion used in a given query (e.g., tail recursion) used in a given query seems quite tricky to infer (and a consistent treatment of this case in the algebraic compiler adds another challenge). Hence, we decided to go for a limited recursion feature in Pathfinder first. We may later on try to add a more generic handling. We are currently implementing a *syntax extension* to Pathfinder that allows to describe a limited notion of recursion. The new construct with $var seeded by expr1 recurse expr2 will have the following semantics: 1. expr1 is evaluated once and then used as a seed to initiate the recursion. $var is bound to the result of expr1 in the first recursion step. 2. Then, expr2 is evaluated over and over. Variable $var is visible in expr2 and for each recursion step will be bound to the union of all items (nodes) obtained in the previous recursion steps. (The results of all recursion steps are collected into the overall result using set semantics.) 3. Recursion terminates if a recursion step does not contribute any new items (nodes) to the overall result (i.e., we reached a fixpoint). (Remark: There still is some discussion if (for performance reasons) each recursion step should only observe the *new* items obtained in the previous recursion step, or whether the entire result set collected so far should be observable in expr2.) The `union' semantics of this new recursion construct implies that we can do recursion only on *nodes*, not on atomic values. This quite directly matches the requirements of the UVA group (and others) that are looking for a "transitive closure" operator. Note that the above syntax extension that we are about to introduce does not interfere with any existing constructs. So our changes will not affect any (existing) valid XQuery expression. Motivation: There is a high demand for transitive closure functionality in the group at UVA (i.e., Loredana and others), but also in other research groups (as I was told). Transitive closure is, e.g., a vital component of an XPath dialect known as "Regular XPath". Regards from Garching Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 Software is like sex: It's better when it's free -- Linus B. Torvalds

3 4

[Monetdb-developers] Compilation warnings MonetDB/SQL
by Fabian Groffen 25 Sep '06

25 Sep '06

For what it is worth, here is a list of warnings produced when compiling MonetDB/SQL. MonetDB itself appears to be mostly warning free. Making and installing MonetDB/SQL in /ufs/fabian/scratch/vtmp/build-current-monetdb-pegasus.ins.cwi.nl/sql /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_table.mx: In function 'table_delete': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_table.mx:223: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_table.mx: In function 'table_check': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_table.mx:266: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'schema_get_table': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:1177: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_kc': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4069: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_key': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4084: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_ic': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4113: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_idx': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4128: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_tc': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4151: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_trigger': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4165: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_column': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4187: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_table': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4240: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_func': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4264: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4265: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sql_trans_drop_schema': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4413: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sql_trans_alter_null': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4717: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sql_trans_alter_default': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4741: warning: comparison between signed and unsigned sql_parser.y:404.8-12: warning: symbol CHECK redeclared sql_parser.y:408.16-23: warning: symbol DISTINCT redeclared sql_parser.y:410.41-46: warning: symbol HAVING redeclared conflicts: 21 shift/reduce, 44 reduce/reduce sql_parser.y:404.8-12: warning: symbol CHECK redeclared sql_parser.y:408.16-23: warning: symbol DISTINCT redeclared sql_parser.y:410.41-46: warning: symbol HAVING redeclared conflicts: 21 shift/reduce, 44 reduce/reduce /ufs/fabian/scratch/monetdb/current/sql/src/server/sql_select.mx: In function 'sql_binop': /ufs/fabian/scratch/monetdb/current/sql/src/server/sql_select.mx:924: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/server/sql_scan.mx: In function 'scanner_string': /ufs/fabian/scratch/monetdb/current/sql/src/server/sql_scan.mx:562: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/server/rel_select.mx: In function 'rel_binop': /ufs/fabian/scratch/monetdb/current/sql/src/server/rel_select.mx:2878: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx: In function 'mvc_dump_1': /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:252: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx: In function 'mvc_dump_2': /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:269: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx: In function 'dump_1': /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:286: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx: In function 'dump_2': /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:303: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx: In function 'dump_3': /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:322: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx: In function 'backend_dumpstmt_': /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:371: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:377: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:392: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:407: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:417: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:427: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:821: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:834: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:850: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:856: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:873: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:876: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:924: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:946: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:966: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:972: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:975: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1032: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1042: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1081: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1149: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1151: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1153: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1155: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1157: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1160: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1260: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1283: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1301: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1303: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1351: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1416: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_result.mx: In function 'convert2str': /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_result.mx:564: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/odbc/driver/ODBCConvert.c: In function 'ODBCFetch': /ufs/fabian/scratch/monetdb/current/sql/src/odbc/driver/ODBCConvert.c:1133: warning: signed and unsigned type in conditional expression /ufs/fabian/scratch/monetdb/current/sql/src/odbc/driver/ODBCConvert.c:1418: warning: signed and unsigned type in conditional expression /ufs/fabian/scratch/monetdb/current/sql/src/odbc/driver/SQLConnect.c: In function 'SQLConnect_': /ufs/fabian/scratch/monetdb/current/sql/src/odbc/driver/SQLConnect.c:93: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/odbc/driver/SQLConnect.c:111: warning: comparison between signed and unsigned

2 2

Re: [Monetdb-developers] Error with the Java Client
by Jim Foley 24 Sep '06

24 Sep '06

> Date: Sat, 23 Sep 2006 09:56:44 +0200 > From: Fabian Groffen <Fabian.Groffen(a)cwi.nl> > Subject: Re: [Monetdb-developers] Error with the Java Client > To: monetdb-developers(a)lists.sourceforge.net > Message-ID: <20060923075643.GB21350(a)cwi.nl> > Content-Type: text/plain; charset=utf8 > > On 22-09-2006 23:44:20 -0400, Jim Foley wrote: > > Fabian, > > > > I can accept that my transaction is invalid and there is no way to > > tell what the state of tables/object is but I cannot except that a > > fatal java exception is what is expected. I would expect a > java error > > stating that the state of the database is unknown and > please roll back > > the last transaction. > > > > Am I expecting too much from open software? > > No, I just never tried doing this. I just fixed this in CVS, thanks. Thank you, Fabian. I will download the new code and try it out. Hopefully once I get to know the code better I will be able to help you out with some of these problem. Jim

1 0

Re: [Monetdb-developers] Error with the Java Client
by Jim Foley 23 Sep '06

23 Sep '06

Fabian, I can accept that my transaction is invalid and there is no way to tell what the state of tables/object is but I cannot except that a fatal java exception is what is expected. I would expect a java error stating that the state of the database is unknown and please roll back the last transaction. Am I expecting too much from open software? Jim > Message: 5 > Date: Fri, 22 Sep 2006 16:57:03 +0200 > From: Fabian Groffen <Fabian.Groffen(a)cwi.nl> > Subject: Re: [Monetdb-developers] Error with the Java Client > > Hi Jim, > > On 22-09-2006 10:47:13 -0400, Jim Foley wrote: > > voc-> start transaction; > > Operation successful > > > > auto commit mode: off > > voc-> select * from tables; > > Error: SELECT: no such table 'tables' > > Your transaction died here ... > > > voc-> > > voc-> create table test > > voc=> (id int, jimnum decimal(38,2)); > > Error: current transaction is aborted (please ROLLBACK) > > ... hence the error message you need to rollback > > > voc-> \d > > A fatal exception occurred: java.sql.SQLException: current > transaction > > is aborted (please ROLLBACK) > > This might be a bit hefty, but in fact is expected behaviour, > since your transaction has been invalidated, so it is unknown > what tables/objects there should be at this moment. > > > > ------------------------------ >

2 1

[Monetdb-developers] Error with the Java Client
by Jim Foley 22 Sep '06

22 Sep '06

I am doing some testing with MonetDB and the java client. I have a repeatable error that I am not sure if it is a but or the way I am using the tool. I have an Oracle background so it could be me. Java client connection on Windows 2000 Professional to MonetDB on openSuSe 10.1 using SQL. Thanks for your help. Jim Foley C:\MonetDB Client>java -jar jdbcclient-1.4.jar -h 192.168.1.101 -d demo -u voc password: Welcome to the MonetDB interactive JDBC terminal! Database: MonetDB 4.13.1 Driver: MonetDB Native Driver 1.4 (Dilate 20060918) Type \q to quit, \h for a list of available commands auto commit mode: on voc-> \d voc-> start transaction; Operation successful auto commit mode: off voc-> select * from tables; Error: SELECT: no such table 'tables' voc-> voc-> create table test voc=> (id int, jimnum decimal(38,2)); Error: current transaction is aborted (please ROLLBACK) voc-> \d A fatal exception occurred: java.sql.SQLException: current transaction is aborted (please ROLLBACK) java.sql.SQLException: current transaction is aborted (please ROLLBACK) at nl.cwi.monetdb.jdbc.MonetConnection$ResponseList.executeQuery(MonetConne ction.java:2292) at nl.cwi.monetdb.jdbc.MonetConnection$ResponseList.processQuery(MonetConne ction.java:2045) at nl.cwi.monetdb.jdbc.MonetStatement.internalExecute(MonetStatement.java:3 57) at nl.cwi.monetdb.jdbc.MonetStatement.execute(MonetStatement.java:326) at nl.cwi.monetdb.jdbc.MonetStatement.executeQuery(MonetStatement.java:390) at nl.cwi.monetdb.client.JdbcClient.processInteractive(JdbcClient.java:646) at nl.cwi.monetdb.client.JdbcClient.main(JdbcClient.java:476) C:\MonetDB Client>

2 1