Issue Details (XML | Word | Printable)

Key: CORE-3708
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Dmitry Yemanov
Reporter: Pavel Zotov
Votes: 0
Watchers: 4
Operations

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

Add actual configuration settings to the monitoring tables

Created: 23/Dec/11 05:47 AM   Updated: 22/Jan/19 05:35 PM
Component/s: None
Affects Version/s: None
Fix Version/s: None

Issue Links:
Duplicate
 


 Description  « Hide
An application can not obtain server build (like `WI-V2.5.2.26390`), server architecture (classic / SC / SS / embed) and port number (in case of TCP using),
via context variables.
Can these data be added to SYSTEM namespace (for using with RDB$GET_CONTEXT() function) or just new built-in variables like current_connection et al ?

Encompassing question: is it possible to get all the settings from firebird.conf via context variables or new MON$-table (e.g. 'MON$SERVER_SETTINGS') ?
// especially interesting for: TempDirectories, AuditTraceConfigFile, DefaultDbCachePages, FileSystemCacheThreshold and MaxUnflushed* parameters

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dmitry Yemanov added a comment - 23/Dec/11 05:51 AM
Why do you need to know the build number, architecture and port number?

Dmitry Yemanov added a comment - 23/Dec/11 06:01 AM
Also, it makes very little sense to return the setting from firebird.conf, as overrides are possible at other levels. I'd rather think about returning the actual values used by the engine at runtime.

Pavel Zotov added a comment - 23/Dec/11 06:03 AM
when i run some tests inside isql i often forget which exactly server version (build and architecture) is in test now.
port number may be useful to know only inside application - just to get it more quickly than open firebird.conf on server console

Dmitry Yemanov added a comment - 23/Dec/11 06:19 AM
"show version" in ISQL should report the build number. The server arch term is getting outdated with FB3, something different should be returned instead. As for the the server port number, it's currently unknown inside the engine, thus hardly possible to return. Also, imagine two CS instances listening on different TCP ports but sharing the same database. So the server port number should be a connection property, not the server one.

Pavel Zotov added a comment - 23/Dec/11 06:23 AM
ps. also, as admin i want to restrict access to /opt/firebird folder for any common developer but let him obtain info about some configuration parameters.

Pavel Zotov added a comment - 23/Dec/11 06:27 AM
>"show version" in ISQL should report the build number.
this is not programmatical way!
i mean that an application must 'see' such info via calls rather than isql console

>The server arch term is getting outdated with FB3
currently there is no FB 3.x. even in beta.
most people works in 2.0 / 2.1 / 2.5.

Dmitry Yemanov added a comment - 23/Dec/11 06:39 AM
You were speaking about the user's way ("I often forgot which version is connected to"), not the programmatical way! And it's useless information for the application, because the feature set is uniquely identified by <major ver>.<minor ver>.<sub ver>. Build number could be actual for some intermediate (snapshot) build but relying on that in the application is terribly wrong.

FB 2.x are unlikely to get any new features, especially the ones that won't make any sense in the subsequent versions.

Dmitry Yemanov added a comment - 23/Dec/11 06:42 AM
Providing the "common developer" access to the configuration sounds like a security risk. It's also seems useless in general, e.g. if the global config says "cache size = 75", the database-specific config says "cache size = 1000" and the application overrides this with "cache size = 10000" at runtime.

Sean Leyne added a comment - 23/Dec/11 04:34 PM
Pavel why do you open tracker cases only to have them, in most cases, be rejected. Please stop this usage pattern.

The project Support, Dev and Architecture mailing lists are the correct forum to present your ideas. These are where ideas can be reviewed and discussed with the widest audience.

Then, if the issue has not been "rejected", you can open a tracker case with the details which have been agreed to.

Vlad Khorsun added a comment - 28/Dec/11 10:59 PM
Dmitry,

> I'd rather think about returning the actual values used by the engine at runtime.

You've got my voice :) I think this is must have feature, especially in FB3 where configuration will be more complex than now.
BTW, MSSQL already have this feature, don't know about others