Skip to content
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

Get more actions with context variables [CORE2941] #3323

Open
firebird-automations opened this issue Mar 24, 2010 · 3 comments
Open

Get more actions with context variables [CORE2941] #3323

firebird-automations opened this issue Mar 24, 2010 · 3 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @pavel-zotov

Votes: 4

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).

@firebird-automations
Copy link
Collaborator Author

Commented by: Paulo França Lacerda (paulo_franca_lacerda)

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?

@firebird-automations
Copy link
Collaborator Author

Commented by: Mykhaylo Masyk (miwa)

>> 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.

@firebird-automations
Copy link
Collaborator Author

Commented by: Ain Valtin (ain)

<<
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).
>>

CORE1863

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant