Issue Details (XML | Word | Printable)

Key: CORE-2941
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Pavel Zotov
Votes: 4
Watchers: 3
Operations

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

Get more actions with context variables

Created: 24/Mar/10 05:50 AM   Updated: 27/Mar/11 04:45 AM
Component/s: UDF
Affects Version/s: 2.5 RC2
Fix Version/s: None


 Description  « Hide
It wolud be useful to add functionality for manipulating with context variables, such as:
1) make limit of context variables (currenlty 1000) be configurated via .conf file (e.g. CONTEXT_VARS_LIMIT parameter);
2) get current count of variables that are stored in context of specified `namespace`, e.g.:
     rdb$get_current_context_volume('namespace') ==> return count of variables in context
    rdb$get_current_context_capacity('namespace') ==> return CONTEXT_VARS_LIMIT - rdb$get_current_context_volume('namespace')
3) clear all the list of variables that were previously set (something like rdb$clear_context('namespace'), return: old capacity of context that was before deletion);
4) return full list of currently stored context variables (like selective stored procedure, e.g.: rdb$get_context_content('namespace') ==> returns a set of rows with two columns: ctx_name, ctx_value)

Also, as developer I want to be able to create some "new" namespace (e.g. 'ALL_CONNECTIONS') that will be common for ALL connections (and will be modified with proper syncronization via locks, of course).

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Paulo França Lacerda added a comment - 24/Mar/10 05:29 PM
I've been thinking of such current limitations too but ended up sticking with my own UDFs for clearing/adding/deleting/querying custom context variables and found it far better, because:

1 - It's easy to implement UDFs for context variables in ANY namespaces I whish.
2 - I can stored them as I want without the limits imposed by Firebird releases.
3 - I can easily setup initial values within a "on connect" trigger as I'd do if usng rdb$set_context (for "per user" namespaces) and also "per server session" by defining initial values as my UDF library is loaded).
4 - I don't need to use tables. I use (Delphi style) dynamic arrays. Far faster.
5 - I can even save/restore variables to/from a file directly, if I want it to be persistent.
6 - No need for waiting for oficial enhencements or fixes on rdb$xxx_context.
7 - More control, less dependency... more hapiness. :)

Question:

What are the advantages of using rdb$xxx_context over self-made UDF-based replacements?

Mykhaylo Masyk added a comment - 25/Mar/11 09:07 PM
>> What are the advantages of using rdb$xxx_context over self-made UDF-based replacements?

Only one. You have working decision out of the box and don't need to support own cool delphi udf under (64-bit) linux.

Oh. Points from 3 to 7 will be the same for any salf-made tool. And they will be very cool and useful. Until on some day your db/app need to be run on some other platform. Or by some other administrator/developer.

So, just +1 to the ticket from some FB user.

Ain Valtin added a comment - 27/Mar/11 04:45 AM
<<
It wolud be useful to add functionality for manipulating with context variables, such as:
2) get current count of variables that are stored in context of specified `namespace`, e.g.:
     rdb$get_current_context_volume('namespace') ==> return count of variables in context
    rdb$get_current_context_capacity('namespace') ==> return CONTEXT_VARS_LIMIT - rdb$get_current_context_volume('namespace')
>>

Perhaps reserving an name (ie your CONTEXT_VOLUME) for this so that existing RDB$GET_CONTEXT API can be used like
RDB$GET_CONTEXT('namespace', 'CONTEXT_VOLUME')...? Then again, having reserved names is usually PITA and backfires sooner or later.

<<
3) clear all the list of variables that were previously set (something like rdb$clear_context('namespace'), return: old capacity of context that was before deletion);
4) return full list of currently stored context variables (like selective stored procedure, e.g.: rdb$get_context_content('namespace') ==> returns a set of rows with two columns: ctx_name, ctx_value)
>>

Once you have (4) implementing (3) yourself is easy...

<<
Also, as developer I want to be able to create some "new" namespace (e.g. 'ALL_CONNECTIONS') that will be common for ALL connections (and will be modified with proper syncronization via locks, of course).
>>

http://tracker.firebirdsql.org/browse/CORE-1863