[cap-talk] How desirable / feasible is a persistent OCAP language?

[Mike Samuel]

2008/7/17 <ihab.awad at gmail.com>:

>
> On Thu, Jul 17, 2008 at 2:59 PM, Mike Samuel <mikesamuel at gmail.com> wrote:
>
>> What's wrong with database triggers?
>>
>
> They introduce surprising and often subtle changes in the underlying
> dataset, but the semantics of your communication with the dataset do not
> permit you to be notified of them.
>
> Say I set a trigger that says, every time Mike submits something to SVN,
> give him a 5% salary raise. That's well and fine (especially for Mike). But
> the poor person who has implemented a salary viewer app has no clean way to
> register as a listener on the "salary" field of the information representing
> Mike so as to keep their app up to date. Any data caching they have
> implemented is now completely broken since they are implicitly relying on
> invariants that don't exist.
>
> If your database were programmed in a ${real_language} and you could
> communicate with it via a ${real_protocol}, you can build whatever semantics
> you want depending on your application. Yes, it would essentially be a big
> pile of "triggers" but, with a real programming system at your disposal, you
> could build a real distributed system.
>

Is your complaint that triggers are used to directly cause non-local
database changes?  That is a reasonable constraint, and would seem to fit in
your dislike of PL/SQL.

But this is wrong.  Triggers give you a way to get exactly those kinds of
notifications.  You can add a trigger to the salary field so that the
database sends you a notification when it changes.

I think that's how most of these enterprise messaging buses work.  There's a
bunch of clients that subscribe to events of various kinds.  One of the many
sources of events is database triggers.  So you have one persistent
object-store (the database + orb layer), an asynchronous pub-sub system (the
message bus), and a bunch of clients that can then change their part of the
database.  This architecture has problems, but it does a nice job of keeping
the number of writers to any table small, and avoids the problems caused by
frequent polling and batch jobs, which was the norm prior.





>
> Ihab
>
> --
> Ihab A.B. Awad, Palo Alto, CA
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20080717/cd237cb3/attachment.html