Commented by: Alice F. Bird (firebirds)

Date: 2006-03-31 00:13
Sender: bubble76
Logged In: YES
user_id=730078

But I see one problem for the "pull"-variant:
If I store the event-belonging data in a table, I don't know
when I can delete it - because I don't know how many clients
listen to the event.
It's possible to build sepearate tables where the client
"register" for an event, and where the client stores if the
event-belonging data is catched. And if all clients catched
the data, it will be deleted by a trigger/sp. But it seems a
little tricky...
Maybe there is a solution like the stack-trace for
PSQL-exceptions in FB2.

Commented by: Alice F. Bird (firebirds)

Date: 2006-01-06 09:14
Sender: dimitr
Logged In: YES
user_id=61270

What you suggest is a hack against the architecture. It can
be easily done, but it breaks the original intentions behind
events. They're not designed to store tons of data on the
server and send it across the wire on every commit. IMO,
parameter-aware events should use a "pull" approach
(parameter values are fetched by the client) instead of the
current "push" one (data is unconditionally sent to the client).

Commented by: Alice F. Bird (firebirds)

Date: 2006-01-06 02:12
Sender: bubble76
Logged In: YES
user_id=730078

I know that this requires an new mechanism for the events.
So consider it as a feature-request for FB 3/3+.
But I think if it it possible to submit parameters of global
variables it would be easy to submit every type of
parameter. For example this could be useful to submit the
primary-key of a changed dataset.
A way to change the architecture not so far could be to save
the CURRENT_-variables on a stack at the time the event is
fired. And give the clients the possibility to get this
values by an API-function.

Commented by: Alice F. Bird (firebirds)

Date: 2005-12-27 14:45
Sender: dimitr
Logged In: YES
user_id=61270

I'm afraid there won't be an ability to pass any arbitrary
parameter along with the event. It could be possible to
allow some predefined global arguments (some of the CURRENT_
variables), but it's also not compatible with the current
events architecture. After researching this subject a lot,
I'm inclined to think that a new mechanism is required for
this purpose.

Commented by: PEAKTOP (peaktop)

why You can not do some like this ?

declare variable p_event varchar(..);
begin
p_event = 'MyEvent' || current_user || cast(http://new.ID as varchar(8));
post_event :p_event;
end

Commented by: @dyemanov

It requires all IDs to be registered at the client side. Nobody needs such a feature.

Commented by: Mercea Paul (m24paul)

There are situations where is necessary to have more information from that event (without using a table,generator or something else) especially in multi user systems.
I would extend current post_event to something like :

post_event_ex('MYEVENT',http://new.id);

Commented by: Janos Gerevich (nagypapi)

I am using jaybird with events

In my case I have a multi user environment.
I want the user who updates the db and creates the event not to react on that event.

The problem is how can a client know, that the event was generated by him?

In the current event mechanism I'd have to post an event appending an id at the end of it's name.
But then I'd have to be registered to get that event, and all clients would have to be registered to get all id-ended events
-> id's have to be known beforehand and all clients need to be registered for all ids.
=> this needs quite a bit of architectural overhead (table for storing id-s, being able to lease static ids uniquely to clients, etcetc).

Commented by: @livius2

I suppose that this will be simplier to implement:

add possibility to listen to all events without registering explicit name
and after registering "all events listener" we will be notified about any event

and then in client application we can simply get usefull info from name of event :)

Commented by: @dyemanov

The current events architecture is not suitable for such a change, unfortunately.

Commented by: @livius2

I think about this and i see that you are worry about
older users applications.
With this modification all older aplications will be corrupted

i think and this can be solved by new functions
like POST_EVENT_EX(...) and for listen to this event user must use new API
this not breake existing code :-) but extend functionality :)

Commented by: Franz J Fortuny (frafor49)

I was using successfully (prior to version 2.5.3):

These are the events that the database posts according to real time events:

post_event 'newmsg'||new.idu; which is triggered when a new message from another user is inserted for user IDU. Of course, user's IDU task only REGISTERS to listen to events 'newmsg'+IDU (a string).

another event:

post_event 'usrin'||new.idc, where IDC is the COMPANY ID. All users in that company register to listen for events 'usrin'+IDC; they don't need the events for other companies.

or for a chat system:

the user registers for event: 'chat'+IDU, where IDU is the user's ID.

the event post_event 'chat'||new.idu is only interesting for user IDU, not for any other user.

The above combined with php ibase_wait_event($ev1,$ev2,$ev3), which returns a STRING for the corresponding event that was triggered and then executes a query in order to fetch the chat message, or to fetch the user that left, etc.

$ev = ibase_wait_event($ev1,$ev2,$ev3...)

The above was working in a Linux server with less power. I moved the application to a server with a lot more memory, more CPU's and the database is now on an SSDrive, but is not working anymore!

The database is sending a wrong and arbitrary message; that is, the return of the $ev = ibase_wait_event($ev1,$ev2...) IS NOT what is expected.

Nothing else changed.

BTW: this approach is very simple; if you enroll to listen to events like "chat", then every single time a chat is added, you need to check if it was for you; on the other hand, if you register to listen to 'chat'+ID, then you only fetch the message that is interesting for you; less work for the database, although it must keep for events alive.

By the way, firebirdSQL 2.5.3 gets "fat" as it is used in the amount of memory it is using, and remains "fat" even when idle.

Commented by: Sorien (sorien)

pls consider parametred events like in postgres or listening to all events for 4.0

Commented by: Thijs van Dien (thijsvandien)

If we cannot easily have truly parametrized events, much of the use cases for those could be covered by a combination of two simpler extensions:
- Sufficiently long event names (1024 characters?)
- Support for wildcards (or regex even?) in names to subscribe to
With that, any suitable serialization format could be used to encode what would otherwise have been parameters.

Commented by: Rafael Dipold (dipold)

I nice feature for Firebird too:
https://community.embarcadero.com/blogs/entry/interbase-change-views-part-1-what-is-a-change-view

Commented by: Ertan Kucukoglu (ertank)

It would really be one of the very useful features having a message (even a limited length) delivered to client (in a way of pull/push doesn't matter much as this will be the driver or database component's job) with event. Just like in PostgreSQL's NOTIFY.

I am working on a Windows service application which will listen to events sent from triggers. When certain event occurs, application will be sending e-mail to relevant users based on inserted/updated data. I looked for that feature implemented a lot to minimize database query count and decrease table count as current way of events not helping to identify relevant record. Since it is multi-user environment, I cannot find it as the latest inserted record in table. It is almost impossible to identify updated record without adding new tables in database.

I am 100% sure there will be a lot more valid use cases than mine above.

It has been constantly requested in time. Please, consider a way to add this feature.