Martijn Tonies wrote:

> Hi Jim,
>
>
>> The NimbusDB architecture is a SQL engine floating on a set of
>> distributed objects. The SQL engine required a notification mechanism
>> for metadata updates performed on another node.
>>
>> The Firebird event alter mechanism is patented by Borland, and was
>> consequently a non-starter. That said, utilizing it for all possible
>> metadata update events would have been cumbersome, to say the least.
>>
>> After the expenditure of a suitable amount of hot water, I came up with
>> a scheme that I can live with. While simpler to use than the Firebird
>> event alerter mechanism, it is really targeted at a slightly different
>> problem domain. That said, here is a brief description.
>>
>> First, a new metadata object type, an event declaration. The syntax:
>>
>> create table_event <event name> for [<schema name>.] <table name> (
>> <field name> [, <field name]...)
>>
>
> This is quite different from Firebird events and their usage, for example,
> when
> executing a long running stored procedure asynchronously, one would register
> interest in an event with a specific name and get notified once it finished
> (by the
> procedure). This is much harder when you have to create events as metadata
> (assuming the mechanism would be extended for non-table-bound events).
>
>
>> Event names are local to a table. The table and fields must, of course,
>> exist.
>>
>
> Why specifically for tables?
>
>

I guess the short answer is, that is where the data is. The longer
answer is that is solved a specific problem that may or may not generalize.

The key difference between NimbusDB and Firebird events is that NimbusDB
events carry before and after data while Firebird events are just
"something happened".


--
Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376



[Non-text portions of this message have been removed]