Bugs item #2881239, was opened at 2009-10-18 13:09
Message generated for change (Settings changed) made by mr-meltdown
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2881239&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: SQL/Core
Group: SQL "candidate"
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Martin Kersten (mlkersten)
>Assigned to: Fabian (mr-meltdown)
Summary: SQL: mclient formatting issues
Initial Comment:
Make a file x with the content "trace select * from tables:"
run:
m...@eir::~/tpch> mclient -lsql -fsql <x
+------------------------------------------------------------------------------+
| 2 usec mdb.setTimer(true); |
| 1 usec @0 mdb.setThread(true); |
| 5 usec @0 barrier _292 := language.dataflow(); |
+--------------------------------------+---------------------------------------+
| 8 usec @0 _2:bat[:oid | :sht |
| 4 usec @0 _7:bat[:oid | :oid |
+------------------------------------------------------------------------------+
| 5 usec @0 _9<tmpr_2074>[0 |
+--------------------------------------+---------------------------------------+
| 4 usec @0 _7:bat[:oid
The formatting is screwed up.
----------------------------------------------------------------------
>Comment By: Fabian (mr-meltdown)
Date: 2009-10-27 14:30
Message:
all formatting issues are resolved now the faulty trace renderer has been
removed.
----------------------------------------------------------------------
Comment By: Martin Kersten (mlkersten)
Date: 2009-10-24 23:08
Message:
The SQL trace facility has been changed. The events are collected in BATs
and printed after the result set has been sent. The table-based rendering
of this information can be further improved.
----------------------------------------------------------------------
Comment By: Martin Kersten (mlkersten)
Date: 2009-10-24 23:08
Message:
The SQL trace facility has been changed. The events are collected in BATs
and printed after the result set has been sent. The table-based rendering
of this information can be further improved.
----------------------------------------------------------------------
Comment By: Sjoerd Mullender (sjoerd)
Date: 2009-10-22 16:57
Message:
The main problem is in the data being generated. After the recent changes,
the trace output is output with a leading `=' which makes mclient think
that bit is a single column table. However, this is interspersed with the
output of the query being traced. This confuses the hell out of mclient.
A possible solution is to collect the trace output in a table on the
server, and then outputting the table at the end of the query as an extra
SQL result set.
Another solution could be to suppress the query output and only output the
trace results. After all, you prepend the query with the trace keyword
because that is the output you want to see. If you want the query result,
omit the trace.
In any case, bouncing this back to Martin.
----------------------------------------------------------------------
Comment By: Fabian (mr-meltdown)
Date: 2009-10-18 19:56
Message:
seems to me this got introduced when the TABLEformatter was introduced,
which is not so recent.
----------------------------------------------------------------------
Comment By: Martin Kersten (mlkersten)
Date: 2009-10-18 19:52
Message:
Yes, timing information, like debugging information, is not in strict tuple
field format.
Therefore, in mclient the state of computation (trace,debug modes) was
used for rendering decisions.
Whose semantics seems to got lost in the recent modifications.
To align the raw mode required, i will change the marker to '#'. This way
all values returned as comment
can be cast as a string covering all columns in mclient. Even replacing |
into #
----------------------------------------------------------------------
Comment By: Fabian (mr-meltdown)
Date: 2009-10-18 18:05
Message:
Actually, it sees the comma and splits on it. I don't understand why it
behaves differently when executed via doFileByLines vs. doFile. However,
we can trace back the rendering garbage to the server not adhering the
protocol.
----------------------------------------------------------------------
Comment By: Fabian (mr-meltdown)
Date: 2009-10-18 17:48
Message:
the server sends stuff like this:
[ 4 usec _138<tmp_1216>[26] :=
bat.append(<tmp_1216>[26],<tmp_1217>[0],true); ]
which is neither a quoted string, nor a string that doesn't contain
potentially confusing chars like ]
It remains weird that the rendering differs depending on how the data is
fed into mclient.
----------------------------------------------------------------------
Comment By: Fabian (mr-meltdown)
Date: 2009-10-18 13:39
Message:
that actually would best be done just at the server end by emitting two
columns...
----------------------------------------------------------------------
Comment By: Martin Kersten (mlkersten)
Date: 2009-10-18 13:24
Message:
Alternatively, there would be a two-column table, separating the timing
from the instruction itself
----------------------------------------------------------------------
Comment By: Martin Kersten (mlkersten)
Date: 2009-10-18 13:22
Message:
The expected output was
sql>trace select * from tables;
| 6 usec mdb.setTimer(true);
|
| 1 usec @0 mdb.setThread(true);
|
| 21 usec @0 barrier _292 := language.dataflow();
|
| 10 usec @0 _2:bat[:oid,:sht] <tmp_2320>[0] :=
sql.bind("tmp","_tables","type",0);
|
|
----------------------------------------------------------------------
Comment By: Fabian (mr-meltdown)
Date: 2009-10-18 13:16
Message:
I think you mean the timer information is written in the output, which may
very well be an artifact of a feature request I implemented.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2881239&group_id=56967
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Monetdb-bugs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
