Subject | Re: [Firebird-Architect] Another Model for Database Events |
---|---|
Author | Martijn Tonies |
Post date | 2010-03-16T07:11:10Z |
Hello Jim,
beast by the
same name, right?
NimbusDB events are some sort of triggers that raise a signal back to the
client?
With regards,
Martijn Tonies
Upscene Productions
http://www.upscene.com
Download Database Workbench for Oracle, MS SQL Server, Sybase SQL
Anywhere, MySQL, InterBase, NexusDB and Firebird!
Database questions? Check the forum:
http://www.databasedevelopmentforum.com
>>> The NimbusDB architecture is a SQL engine floating on a set ofSo then it's not really "another model" but rather a slightly different
>>> 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".
beast by the
same name, right?
NimbusDB events are some sort of triggers that raise a signal back to the
client?
With regards,
Martijn Tonies
Upscene Productions
http://www.upscene.com
Download Database Workbench for Oracle, MS SQL Server, Sybase SQL
Anywhere, MySQL, InterBase, NexusDB and Firebird!
Database questions? Check the forum:
http://www.databasedevelopmentforum.com