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]...)

Event names are local to a table. The table and fields must, of course,
exist.

The API is variant on :

void registerEvent (const char *schema, const char *table, const
char *event, EventHandle *handler)

where

class EventHandler
{
public:
virtual void handleEvent(Event *event) = 0;
};

and

class Event
{
public:
virtual int getEventType() = 0;
virtual const char *getEventName() = 0;
virtual const char *getColumnName(int index) = 0;
virtual String getString(bool before, int index) = 0;
virtual int getInt(bool before, int index) = 0;
virtual int64 getInt64(bool before, int index) = 0;
};

The basic idea that internal update operation check for declared
events. For each declared event, it evaluates the fields in the field
list for the before and after record versions, as appropriate. The
event is posted first to a transaction, then, post commit, to an event
manager that delivers the events to any registered handlers.

It would be difficult but not impossible to implement with classic and
straightforward to superserver.

The event altered mechanism is based on the assumption that the number
of events of interest is small compared to the number of possible events
and the likely number of update operations. The NimbusDB assumes that
the number of updates is small, and the probability of interest is
high. For example, if an application wanted to get notified of a status
change for a few employees in a large company, the NimbusDB model would
have to run all employee updates through an event handler while in
Firebird, the event handle would see only events for specific
employees. On the other hand, a SQL engine is likely to consider all
metadata changes to be interesting.


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



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