Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think in the same lines (I'm building a relational lang http://tablam.org) and think a modern RDBMS could be made alike:

    command  "city.define miami" |> event pre-process (ie: validations and transformations!) |> write-ahead log |> fire-observers: [post log for later OR block writes]
The idea is to put some of the stored procedures in the "event pre-process" before commit to write-ahead. In the "fire-observers" steps is possible to directly commit to a table (sync) and get immediate feedback (ie: primary key duplicate) OR store the log to be processed later.

The idea is that is possible to send "events" that are not necessarily "insert into table" or similar, just pure business stuff. BUT still possible to operate as always!



Not sure if this is what you mean but these exist - Oracle Queues, MQSeries, RabbitMQ (open source MQSeries copy), all part of a generic thing called Enterprise Service Bus


I would suggest thinking more along the lines of Kafka/Kinesis/et cetera. ESBs are often not persistent and as a result not available for reprocessing against new use cases or with fixed code.


If the queue is outside the RDBMS, not.

What I say is that RDBMS are too much of a blackbox. I want a way to use them alike legos (but without gettin INTO their source code!).

Imagine you wanna do a bloom index, but the RDBMS not have it. How you do it normally?

Put a handler/listener/event etc that intercept the calls and route if need:

    search ... | if_bloom index_bloom OR continue




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: