Subject | Re: POST_EVENT and it params |
---|---|
Author | Alexander V.Nevsky |
Post date | 2003-07-02T08:05:43Z |
--- In firebird-support@yahoogroups.com, "Martijn Tonies"
<m.tonies@u...> wrote:
transaction. Such an implementation will be suicide for server, client
and network. Dmitry Yemanov and my humble person for a long time
disputed this subject, and reached consent that mix statement-level
logic and functionality with record-level ones is inadmissible.
Parameter of event should be only transaction-statement-level like
event itself. Most obviously I can see Current_Transaction as such a
parameter - we can mark with it any touched record in FB 1.5. and
easily access changes made by transaction having it's statement-level
notifications - events. It is possible to use Current_Connection or
Rows_Affected for example, but not record-level parameters, which will
result in problems with storage of tons of them during transaction's
life and sending tons of events with them at it's commit. Just now we
can implement events with such pre-difined limited parameters, but
have ho decision how to give more freedom for applications developer
without risk to kill server and net.
Best regards, Alexander.
<m.tonies@u...> wrote:
> POST_EVENT 'account.added.' || new.accid;Martijn, Helen, imagine now you inserted 1 000 000 records in one
>
> And listening for:
>
> account.added.*
>
> Etc...
transaction. Such an implementation will be suicide for server, client
and network. Dmitry Yemanov and my humble person for a long time
disputed this subject, and reached consent that mix statement-level
logic and functionality with record-level ones is inadmissible.
Parameter of event should be only transaction-statement-level like
event itself. Most obviously I can see Current_Transaction as such a
parameter - we can mark with it any touched record in FB 1.5. and
easily access changes made by transaction having it's statement-level
notifications - events. It is possible to use Current_Connection or
Rows_Affected for example, but not record-level parameters, which will
result in problems with storage of tons of them during transaction's
life and sending tons of events with them at it's commit. Just now we
can implement events with such pre-difined limited parameters, but
have ho decision how to give more freedom for applications developer
without risk to kill server and net.
Best regards, Alexander.