[MXS-2297] Publish/Subscribe Created: 2019-01-28 Updated: 2022-06-05 Resolved: 2019-09-04 |
|
| Status: | Closed |
| Project: | MariaDB MaxScale |
| Component/s: | N/A |
| Affects Version/s: | None |
| Fix Version/s: | Icebox |
| Type: | New Feature | Priority: | Trivial |
| Reporter: | Dave | Assignee: | Todd Stoffel (Inactive) |
| Resolution: | Won't Do | Votes: | 1 |
| Labels: | None | ||
| Description |
|
May be this in not the rights place for a feature request, in that case I am sorry. However, there is a lot on talk about publish/subscribe methods using varies systems like RabbitMQ and Redis and such. Most of them store messages somehow and alert subscribers that something is has happened. Though SQL is traditionally not considered for such functionality, it would be rather interesting to have it. Especially when integrated in to something like MXS. This would make it much easier to work with both events and a database. Would it be at all interesting to investigate such functionality? Or would this never be accepted by the community? |
| Comments |
| Comment by markus makela [ 2019-01-28 ] |
|
This is exactly the correct place for feature requests but perhaps not the best place for discussions and brainstorming on new features. For that, I'd recommend the maxscale@googlegroups.com mailing list: https://groups.google.com/forum/#!forum/maxscale The idea is sound and is, in some sense, already implemented in MaxScale (see: Avrorouter). The implementation doesn't use the MariaDB/MySQL protocol but does create "events" based on the data stored in a database. There is ongoing development on a C API for the replication protocol for the MariaDB Connector-C. You can find the source code in the 3.1 branch on GitHub in the mariadb_rpl.h header. This would allow you to connect to a MariaDB server and listen for events. The API is a rather low level one so it doesn't give easily accessible data in native formats. What we really need is a use-case that describes what it would be used with and what sort of behavior you'd expect from it. Also knowing what sorts of integrations you'd use it with would help focus on what sort of a feature we actually need. For example, if you're going to integrate it into a monitoring solution having the events exposed in a form that is easily consumable (e.g. JSON via some REST API endpoint) would be important. If you're using it inside an application that already uses an SQL connection, having it as a "SQL-layer" feature would be better. |
| Comment by Dave [ 2019-04-26 ] |
|
I would imagine the use case to be silimar to other systems such as Redis and RabbitMQ but only for simple events, database triggers and such. So a SQL client on the client leven can subscribe to a table for insert, update, delete, create, alter or other statements and do additional processing. And perhaps customs events so clients can use SQL to signal each other that something is up. Many current technologies seem to rather overlap. Anyways I am not much of a C developer to really contribute. |
| Comment by markus makela [ 2019-04-26 ] |
|
Most of that is already implemented by the connector C replication API e.g. detection of insert/update/delete events when row-based replication is in use. It also provides the SQL statements that are executed but it doesn't tell what the effects of the statement were (you'd have to parse that yourself). |
| Comment by Dave [ 2019-04-26 ] |
|
Sorry but I am a PHP developer. I would expect something like `SELECT BLOCK * FROM INFORMATION_SCHEMA.EVENTS e WHERE e.eventTime>=?` and simply get a result set with events matching my query or the query blocking until events match. Implementing the C replication API is beyond me. |
| Comment by Johan Wikman [ 2019-09-04 ] |
|
Too niche. |