New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include client library version and protocol version in mon$attachments [CORE2780] #3171
Comments
Modified by: @dyemanovassignee: Dmitry Yemanov [ dimitr ] |
Modified by: @dyemanovFix Version: 3.0 Alpha 1 [ 10331 ] |
Commented by: @dyemanov Why would you need both the client library version and the protocol version? The latest supported protocol version is always used, so if you know the fbclient version, then you can figure out the protocol one (but not vice versa). Considering that, why would the protocol version be important to know? |
Commented by: Douglas Tosi (douglasht) I agree with you when the client is using fbclient.dll. |
Modified by: @dyemanovstatus: Open [ 1 ] => In Progress [ 3 ] |
Modified by: @dyemanovstatus: In Progress [ 3 ] => Open [ 1 ] |
Commented by: Arioch (arioch) What is exactly the fix ? i searched for "mon$" in http://web.firebirdsql.org/download/snapshot_builds/win/3.0/Firebird-3.0.0.30050-ChangeLog.txt and found nothing related to client version ID |
Commented by: @dyemanov The fix was a new column MON$CLIENT_VERSION in MON$ATTACHMENTS, appopriately reported by any client library starting with v3.0. Older versions (or no client library at all like pure JDBC or .NET Provider connections) will have NULL in this field. Another field has been added to report the network protocol version tag. |
Commented by: Arioch (arioch) why jaybird and .Net Provider are not client libraries ? they transcode internal wire protocol to a persistent published API does that column provide to tell fbclient.dll from fbembed.dll from gds32.dll ? |
Commented by: @dyemanov They don't use fbclient, so they would have to identify them differently. But it could be possible to do that the same way fbclient does it (from the API POV) so that their version would be seen in the same column. |
Commented by: Arioch (arioch) It would be rather nice. And i think wire protocol should have some stricter specifications, so that all the client libs 9native, JVM, CL:R, Python, whatever) acted uniformly regarding every feature. You can say like "JayBord is not Firebird" - but the user, who just downloaded them both from http://firebirdsql.org would never agree |
Commented by: @hvlad > And i think wire protocol should have some stricter specifications If *you* require client version - make check for its presence at ON CONNECT trigger... |
Commented by: Arioch (arioch) wire protocol may have guidelines or even requirements for modern libraries to specify their version |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Resolved [ 5 ] QA Status: Done successfully Test Details: See also test for CORE2006. |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Resolved [ 5 ] Test Details: See also test for CORE2006. => Explanation about prefixes for client version: PS. Test uses SIMILAR TO in order to check format of output. |
Modified by: @cincuranet |
Submitted by: Douglas Tosi (douglasht)
Is duplicated by CORE3938
Is related to QA650
Block progress on DNET652
Having the client library version and protocol version listed in mon$attachments would be useful. For example to track clients that need an upgrade.
Commits: 9f2a992
====== Test Details ======
Explanation about prefixes for client version:
Windows: WI
Linux: LI
MacOS: UI (intel) or UP (powerpc)
Solaris: SI (intel) or SO (spark)
HP-UX: HP
'-T' = Testing; '-V' = RC or release
Sufixes: 'Firebird' followed by space and at least one digit (letter from dimitr 10-apr-2015 09:19)
PS. Test uses SIMILAR TO in order to check format of output.
If it will fail in the future than it can be due to some bugs in SIMILAR TO.
See also test for CORE2006 with list of other tickets related to SIMILAR TO.
The text was updated successfully, but these errors were encountered: