Subject | Re: [Firebird-Architect] NOT UPDATABLE fields |
---|---|
Author | Adriano dos Santos Fernandes |
Post date | 2005-02-26T18:29:55Z |
Leyne, Sean wrote:
1) It's a very common business rule that many types of applications can
benefit from.
2) The engine can use as a hint to reserve less space for record versions.
3) The current options cannot be used by tools and applications that do
metadata inspection.
4) It's more easy to write and more clear to read.
is not something that I plan to use.
But flexibility is a good thing.
Adriano
>Ann,I don't agree.
>
>
>
>>So, the question, as I see it, is do we need a third mechanism?
>>
>>
>
>NO!
>
>What Adriano outlined is an application requirement, not a database
>requirement.
>
>
1) It's a very common business rule that many types of applications can
benefit from.
2) The engine can use as a hint to reserve less space for record versions.
3) The current options cannot be used by tools and applications that do
metadata inspection.
4) It's more easy to write and more clear to read.
>The missing piece that v2.0 provides is connection or transactionIf you are refering to the fact that the flag can be deactivated, this
>context variable which allows for variable to be shared amongst
>separated triggers/SP, without needing to pass them as 'dummy' table
>columns.
>
>
is not something that I plan to use.
But flexibility is a good thing.
Adriano