Subject | Re: constant un trigger/procedure |
---|---|
Author | unordained |
Post date | 2010-03-11T16:00:23Z |
---------- Original Message -----------
From: "svanderclock" <svanderclock@...>
Two additional "solutions":
- Use generators. Set their values to the proper (integer) constants, and always
(always!) call them with gen_id(blah,0). Yes, they'll get messed up if someone
decides to get their 'next value', and it only works for integers ... but at
least you'll have dependencies!
- Use procedures. A simple procedure returns a numeric (or other type) constant.
Comes at the cost of extra procedure call, but you have control over who can
modify the procedure, or even who can use it (admin-only constants?) Also, cached
procedures could make changing the constant on-the-fly a problem, as not all
connections would see the same version of the procedure. (See other recent
discussion about that.) But at least it's a central place to change it.
-Philip
From: "svanderclock" <svanderclock@...>
> a little heavy to do all the time a select :( and also if you misspell------- End of Original Message -------
> the field name the result will be wrong
>
> the purpose of the constant can be also that you can not delete it
> when it's is use in some trigger ...
Two additional "solutions":
- Use generators. Set their values to the proper (integer) constants, and always
(always!) call them with gen_id(blah,0). Yes, they'll get messed up if someone
decides to get their 'next value', and it only works for integers ... but at
least you'll have dependencies!
- Use procedures. A simple procedure returns a numeric (or other type) constant.
Comes at the cost of extra procedure call, but you have control over who can
modify the procedure, or even who can use it (admin-only constants?) Also, cached
procedures could make changing the constant on-the-fly a problem, as not all
connections would see the same version of the procedure. (See other recent
discussion about that.) But at least it's a central place to change it.
-Philip