29.05.2018 2:06, Adriano dos Santos Fernandes wrote:
On 28/05/2018 09:13, Vlad Khorsun via Firebird-devel wrote:
There is still no agreement. Current offers:
- single ON SESSION RESET trigger
- pair of new triggers: BEFORE SESSION RESET and AFTER SESSION RESET
- use existing ON CONNECT and ON DISCONNECT triggers and introduce a way
to distinguish
true connect\disconnect from reset (for ex. new system function like
INSERTING\UPDATING\
DELETING)
I said again my position that got uncommented here:
It was answered, but i can repeat again
Make RESET reset to the state defined after the ON CONNECT trigger,
instead of the initial (before ON CONNECT).
It means we should know what changes was made by ON CONNECT trigger.
I.e. we need to save names and values of context variables, save values
of session properties and save contents of GTT's.
Looks overkill for me.
> So ON CONNECT can define context variables that is not reset.
You mean - all context variables in USER_SESSION namespace that was
assigned by ON CONNECT trigger ? Or you speak about some way to mark
context variables as "DON'T RESET" ?
And add BEFORE / AFTER RESET triggers.
So heavy attachment data may be maintained in session or reset manually
via the AFTER RESET trigger when necessary.
>> I strongly suggest to consider existing DISCONNECT\CONNECT triggers
>> also. I think, most of the code will be the same in both set of events
>> therefore it is very questionable if we need another pair of triggers.
>>
>
> Yes, but for me it seems as a hack. User can always do a single SP and
> call it on both triggers.
Hmm... do you consider INSERT OR UPDATE OR DELETE triggers as hack also ?
Regards,
Vlad
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
