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: 5
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 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
