MySQL Bugs: #71142: Documentation for receiving trace messages is misleading

Bug #71142	Documentation for receiving trace messages is misleading
Submitted:	13 Dec 2013 12:42	Modified:	20 Jun 2015 10:59
Reporter:	Craig Fowler	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	Connector / NET Documentation	Severity:	S3 (Non-critical)
Version:	6.4.4.0	OS:	Any
Assigned to:	Assigned Account	CPU Architecture:	Any

Description:
The documentation at:

https://dev.mysql.com/doc/refman/5.6/en/connector-net-programming-tracing.html

… (but also the more recent versions of this documentation too) is incorrect/misleading where it comes to providing instructions for runtime configuration of tracing for the connector. That is - configuring tracing without using the application configuration file (the configuration example given works just fine).

The way of configuring tracing at runtime described in the documentation suggests creating a TraceSource object instance with an appropriate name and then configuring it. This is misleading - the described mechanism is in fact just a description of what the MySQL connector is already doing within its own internals; it will not help a developer trying to configure tracing. Whilst this information could still be included, it should be explicitly marked as an aside, in order to provide an understanding of the underlying trace architecture.

Following the steps shown in the documentation to configure tracing at runtime will create a useless tracing set-up which will not record any trace data.

The correct way to configure tracing at runtime is to make use of the static object:

MySql.Data.MySqlClient.MySqlTrace

… and to configure the switches and listeners via that object. This object is not mentioned within the documentation though.

How to repeat:
An attachment is forthcoming, presenting a test case project. This project creates a MySQL connection with a configured connection string. The requirements for running it are as following:

Database running on localhost
User ID: test_case (no password)
Schema: sample
The user test_case should have GRANT ALL on the sample schema.

The entry-point creates a connection component and a trace-provider component before executing the test case. The test case is a simple SQL statement which will trigger a MySQL warning by default (truncated numeric data in an INSERT statement).

There are two implementations of the trace provider. They may be tested by commenting/un-commenting the appropriate lines in EntryPoint.cs

* One which does not work, yet follows the instructions provided in the documentation.
* Another which does work, this is the mechanism that the documentation should describe for runtime-configuration of tracing.

Suggested fix:
Update the documentation accordingly.

Test case mentioned in bug report

Attachment: CSF.MySQL.zip (application/zip, text), 7.11 KiB.

Hello Craig Fowler,

Thank you for the report.
Could you please try the latest MySql documentations for Connector/Net and let us know if you are still having the issue.

Thanks,
Chiranjeevi.

Reading the documentation at https://dev.mysql.com/doc/connector-net/en/connector-net-programming-tracing.html - this bug is still valid, yes.

If there is a more recent version of this documentation I can't find it.

Hello Craig Fowler,

Thank you for your feedback.
Could you please try the MySQL Trace Source Object documentation for Connector/Net.
here is clearly described in the manual 
http://dev.mysql.com/doc/connector-net/en/connector-net-programming-tracing-mysql.html

Thanks,
Chiranjeevi.

screenshot

Attachment: 71142.PNG (image/png, text), 53.10 KiB.

Trace results:

Connecting to MySQL...
mysql Information: 1 : 1: Connection Opened: connection string = 'server=localhost;user id=root;database=test;port=3306;password=chiran;logging=True'
mysql Information: 3 : 1: Query Opened: SHOW VARIABLES
mysql Information: 4 : 1: Resultset Opened: field(s) = 2, affected rows = -1, inserted id = -1
mysql Information: 5 : 1: Resultset Closed. Total rows=451, skipped rows=0, size (bytes)=12806
mysql Information: 6 : 1: Query Closed
mysql Information: 3 : 1: Query Opened: SELECT TIMEDIFF(NOW(), UTC_TIMESTAMP())
mysql Information: 4 : 1: Resultset Opened: field(s) = 1, affected rows = -1, inserted id = -1
mysql Information: 5 : 1: Resultset Closed. Total rows=1, skipped rows=0, size (bytes)=9
mysql Information: 6 : 1: Query Closed
mysql Information: 3 : 1: Query Opened: SHOW COLLATION
mysql Information: 4 : 1: Resultset Opened: field(s) = 6, affected rows = -1, inserted id = -1
mysql Information: 5 : 1: Resultset Closed. Total rows=219, skipped rows=0, size (bytes)=7373
mysql Information: 6 : 1: Query Closed
mysql Information: 3 : 1: Query Opened: SET character_set_results=NULL
mysql Information: 4 : 1: Resultset Opened: field(s) = 0, affected rows = 0, inserted id = 0
mysql Information: 5 : 1: Resultset Closed. Total rows=0, skipped rows=0, size (bytes)=0
mysql Information: 6 : 1: Query Closed
mysql Information: 10 : 1: Set Database: test
mysql Information: 3 : 1: Query Opened: select ID,Email from aspnetusers
mysql Information: 4 : 1: Resultset Opened: field(s) = 2, affected rows = -1, inserted id = -1
5e74be6e-b8bd-40c8-b608-ca970d214d08 -- cihran@ora.com
mysql Information: 5 : 1: Resultset Closed. Total rows=1, skipped rows=0, size (bytes)=52
mysql Information: 6 : 1: Query Closed
 Work Done.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".