Alexander Peshkoff wrote:

> On Monday 15 March 2010 22:58:41 Jim Starkey wrote:
>
>> 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.
>>
>
> I've implemented more or less same approach on top of DBF format around 13
> years ago. The main need in it was to have a kind of RI in DBFs. It passed
> all required tests, but did not go into production because the company which
> wanted it and paid for it was first too lazy to use it, and later started to
> use SQL servers.
> Question - is there some handling of inserts and deletes? I've treated it as
> changing from NULL to SomeValue for inserts and on the contrary for deletes.
> It was pretty well for RI.
>

The getEventType() method will tell you whether it was an insert,
update, or delete. Or further down the road, maybe something else.

I haven't quite decided on what to do if somebody asks for a "before"
value for an insert or an "after" value for a delete. Probably throw an
exception...

>
>> It would be difficult but not impossible to implement with classic and
>> straightforward to superserver.
>>
>
> Not too difficult - just one more shared memory object.
>
>

I'm allergic to shared memory. It tends to be limited by a kernel
parameter, the API is klunky, and is always a security and reliability
problem.

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



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