Issue Details (XML | Word | Printable)

Key: CORE-2780
Type: Improvement Improvement
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Dmitry Yemanov
Reporter: Douglas Tosi
Votes: 0
Watchers: 2

If you were logged in you would be able to see more operations.
Firebird Core

Include client library version and protocol version in mon$attachments

Created: 30/Nov/09 08:22 AM   Updated: 12/Jun/16 04:55 PM
Component/s: Engine
Affects Version/s: None
Fix Version/s: 3.0 Alpha 1

Issue Links:

QA Status: Done successfully
Test Details:
Explanation about prefixes for client version:
Windows: WI
Linux: LI
MacOS: UI (intel) or UP (powerpc)
Solaris: SI (intel) or SO (spark)
'-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 CORE-2006 with list of other tickets related to SIMILAR TO.

 Description  « Hide
Having the client library version and protocol version listed in mon$attachments would be useful. For example to track clients that need an upgrade.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dmitry Yemanov added a comment - 30/Nov/09 08:31 AM
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?

Douglas Tosi added a comment - 30/Nov/09 09:19 AM
I agree with you when the client is using fbclient.dll.
But if it is using the .net provider or the java provider, client versions may not make much sense. That's why I thought protocol version would be interesting.

Arioch added a comment - 28/Sep/12 06:12 AM
What is exactly the fix ? i searched for "mon$" in and found nothing related to client version ID

Dmitry Yemanov added a comment - 29/Sep/12 04:56 PM
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.

Arioch added a comment - 30/Sep/12 05:20 PM
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 ?
I think this column should have strict specification for its format...

Dmitry Yemanov added a comment - 01/Oct/12 06:16 AM
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.

Arioch added a comment - 01/Oct/12 08:12 AM
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 would never agree

Vlad Khorsun added a comment - 01/Oct/12 08:38 AM
> And i think wire protocol should have some stricter specifications
It have nothing common with wire protocol.
Application (client library) is free to [not] specify any misc flag in DPB

If *you* require client version - make check for its presence at ON CONNECT trigger...

Arioch added a comment - 01/Oct/12 09:54 AM
wire protocol may have guidelines or even requirements for modern libraries to specify their version