Bugs item #1959269, was opened at 2008-05-07 09:16
Message generated for change (Comment added) made by mr-meltdown
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=1959269&group_id=56967
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: PF/runtime
Group: Pathfinder CVS Head
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Wouter Alink (vzzzbx)
Assigned to: Peter Boncz (boncz)
Summary: XQ+JDBC: protocol violation
Initial Comment:
The MonetDB/XQuery of yesterday seems indeed more stable than the last version.
However, I have difficulty getting the java JDBC driver to work with MonetDB.
We use the JDBC connection extensively in the following way (which works
perfectly with the old backend):
=====================
Connection xqConn =
DriverManager.getConnection("jdbc:monetdb://localhost:50000/database?language=xquery",
"monetdb","monetdb");
Statement st = xqConn.createStatement();
ResultSet rs = st.executeQuery("1+1,\"aap\",<noot/>");
try {
rs.next();
if (rs.getLong(1) != 2) fail("failed to receive expected integer");
rs.next();
if (!rs.getString(1).equals("aap")) fail("failed to receive expected
string");
rs.next();
if (!rs.getString(1).equals("<noot/>")) fail("failed to receive
expected element");
} finally {
rs.close();
}
=====================
However, it doesn't work with the new backend, each query gives a "protocol
violated" SQLException.
----------------------------------------------------------------------
>Comment By: Fabian (mr-meltdown)
Date: 2008-05-07 22:33
Message:
Logged In: YES
user_id=963970
Originator: NO
alternatively one could say that the BugTracker/JDBC* tests fail for
pathfinder/G and should be fixed one way or another ;)
----------------------------------------------------------------------
Comment By: Fabian (mr-meltdown)
Date: 2008-05-07 22:24
Message:
Logged In: YES
user_id=963970
Originator: NO
Thanks Wouter.
quote:
>>>
The second problem is a little bit more tricky and would require
more knowledge about the current mapi-protocol (which i do not have
anymore). I assume that Fabian is the one to ask here, but as he should
stay focused on his thesis. I guess with some documentation on (or
examples
of) the current mapi protocol and by reading serialize*.mx you or i could
do it in little time.
<<<
What needs to be done is trivial considering the protocol. Not much has
changed since we (Wouter and I) made that JDBC support in pathfinder.
Though, one needs to understand that what is emitted right now, IMHO does
not conform to anything. It may work, and may be fast, but it has no way
of reliably finding bounds (or doing sequences).
Therefore, regardless of JDBC, that situation needs to be fixed, unless
there is no interest in any API accessibility for XQuery of course (apart
from piping output of mclient).
That said, it's up to you guys to figure out your spaghetti ;) If you
need help to construct a valid "ResultSet" for JDBC, drop me an email. The
hard part of finding the sequence boundaries and serialising them in the
right form is up to you.
----------------------------------------------------------------------
Comment By: Lefteris Sidirourgos (lsidir)
Date: 2008-05-07 21:53
Message:
Logged In: YES
user_id=1856546
Originator: NO
Hi,
the reason I did this one priority 9 is because I understand that this is
a show-stopper bug and because I understood from our initial e-mails that
this problem emerged the last days, from some recent check-in.
Unfortunately my knowledge is limited on how to fix this bug.
----------------------------------------------------------------------
Comment By: Wouter Alink (vzzzbx)
Date: 2008-05-07 21:35
Message:
Logged In: YES
user_id=621590
Originator: YES
lefteris, i'm glad that you give this bug attention, but perhaps priority
9 is a little overdone.
some background information: fabian and i added the feature of
communicating with MonetDB/XQuery through JDBC about three years ago. back
then it looked to us as if XMLDB (the API proposed by others) wouldn't
survive, and it seems that we were right. therefore we added the special
serialization mode which would return a xquery sequence as a one-column sql
resultset. difference with sql was the fact that different types could
occur in a single column, but this didn't hurt mapi (as fabian already
mentioned, it doesn't really care what it transmits either way). It is
simple, it is simple, and it makes life easier. i don't know if there are
any other MonetDB/XQuery-users who abuse JDBC the same way.
The algebra backend from the beginning only supported the 'xml'
serialization (and this has been communicated). This serialization mode
implies that a result always is a constructed element, and never a
sequence. The reason for this bugreport is that I would like to see two
features being implemented in the algebra version in the same way they are
implemented in the mps version: 1) the 'dm' serialization mode, which
allows xquery sequences to be returned, and 2) the ability to do xquery
through JDBC.
I already tackled the first problem by compiling pathfinder after
replacing xquery(...,"xml",....) by xquery(..., "dm",...) in (i believe it
was) serialize_dflt.mx. I hope this can be made a (runtime?) configuration
option. The second problem is a little bit more tricky and would require
more knowledge about the current mapi-protocol (which i do not have
anymore). I assume that Fabian is the one to ask here, but as he should
stay focused on his thesis. I guess with some documentation on (or examples
of) the current mapi protocol and by reading serialize*.mx you or i could
do it in little time.
----------------------------------------------------------------------
Comment By: Lefteris Sidirourgos (lsidir)
Date: 2008-05-07 14:27
Message:
Logged In: YES
user_id=1856546
Originator: NO
Changed the priority to highest because this is an important bug.
----------------------------------------------------------------------
Comment By: Fabian (mr-meltdown)
Date: 2008-05-07 11:02
Message:
Logged In: YES
user_id=963970
Originator: NO
mapilib (mapiclient) is extremely lax towards the protocol. It can do
that as it usually just dumps exactly what it received on the stream, not
caring about the contents at all. JDBC on the other hand relies on the
correctness of the protocol, as it needs to determine correct actions for
each and every response it receives. Chances are big you just didn't
notice the protocol is violated, because mclient didn't warn you something
is wrong, but just dumped the output.
----------------------------------------------------------------------
Comment By: Jan Rittinger (tsheyar)
Date: 2008-05-07 10:57
Message:
Logged In: YES
user_id=993208
Originator: NO
Fabian is right. The problem arises in the server-side MIL code
generation.
The dirty tricks Peter played with the variable of name genType (modifying
the generated internal MIL tree) do not work for the algebra version (and I
don't know why). Because the strange side-effects to the genType MIL
variable do not affect the value of the variable the serialization always
uses the serialization mode 'xml' instead of the JDBC or MAPI mode. (If I
think some more I don't even know why client side querying works as the
special '=' characters at the beginning of the line are not generated.)
----------------------------------------------------------------------
Comment By: Fabian (mr-meltdown)
Date: 2008-05-07 10:49
Message:
Logged In: YES
user_id=963970
Originator: NO
here is the communication log for above example:
RD 1210082838966: read final block: 20 bytes
RX 1210082838966: :mserver:8:plain:LIT
RD 1210082838966: inserting prompt
TD 1210082838966: write final block: 43 bytes
TX 1210082838966: BIG:monetdb:{plain}monetdb:xquery:database:
RD 1210082838968: read final block: 69 bytes
RX 1210082838968: #MonetDB v4 doesn't have multiple database support,
argument
ignored
RD 1210082838968: inserting prompt
TD 1210082838968: write final block: 11 bytes
TX 1210082838968: Xoutput seq
RD 1210082838968: read final block: 0 bytes
RX 1210082838968:
RD 1210082838968: inserting prompt
TD 1210082838996: write final block: 4 bytes
TX 1210082838996: s1+1
RD 1210082839002: read final block: 2 bytes
RX 1210082839002: 2
RD 1210082839002: inserting prompt
----------------------------------------------------------------------
Comment By: Fabian (mr-meltdown)
Date: 2008-05-07 10:45
Message:
Logged In: YES
user_id=963970
Originator: NO
for the record:
it is a true violation, as the server returns:
2
which is clearly a violation, as it should have been
=2
or
[ 2 ]
or
[ "2" ]
NotMyBug.nl :)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=1959269&group_id=56967
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Monetdb-bugs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
