Events

[nawarian]

Does anyone have the intention to use events with relational?

Yes, events. Like... dbms's triggers... Anyone?

[henriquemoody]

That would be nice!

Unfortunately I cannot code this features for these days, I'm pretty busy with other stuff and we have just a few active collaborators.

[nawarian]

can I start it?

[williamespindola]

You can start this @nawarian
How you intend to do this?

[nawarian]

ahmmm...

Thought about writing a simple subscribe/dispatch interface for Collections.

Those would have "onInsert", "onUpdate" and "onDelete" dispatchers available
for subscribing.

What you guys think about it?

[henriquemoody]

Despite this feature have been never requested before, I was thinking about something more flexible, since we are thinking about it now. I was thinking about these events:

• Pre insert
• Post insert
• Pre update
• Post update
• etc...

As you see, there are many events and just write methods doesn't look good idea, but using something like EventDispatcher does. Actually, even with just few events, writing new methods will make Mapper just bigger than it already is.

Any thoughts, @Respect/troubleshooters?

[nawarian]

Agreed.
Would we use a external EventDispatcher/Listener API or create a Respect's?

Is kind of simple, we could create as a module.

[williamespindola]

I thought better about this implementation and I'm trying to find for your real benefits.
Since triggers are already events dispatched by dbms, the Relation should just create than and not dispatch. To create we can use Respect\Db like this:

$db = new Db(new Pdo('sqlite:mydb.sq3'));
$db->query("CREATE TRIGGER salary_trigger
    BEFORE UPDATE ON employee_table
    REFERENCING NEW ROW AS n, OLD ROW AS o
    FOR EACH ROW
    IF n.salary <> o.salary THEN

    END IF;
;")->executeStatement();

My thinking is correct?

[nawarian]

How could I dispatch it to a external application?

Think about pub/sub model, for example.
I would like do publish a data insert to my channel, so others can deal with it to.

This event functionality can handle this and make my code more decoupled.

Can't see how to perform the same with using databases's triggers.

[williamespindola]

So think this is an event dispatcher only. Out of Respect\Relational. And your can use any one like synfony or zend event dispatcher to work with relational. Not a Trigger.

[nawarian]

Yes, an event dispatcher. But integrated with inserts, updates and deletes being processed with Respect.

Like @henriquemoody just said, not only events to dispatch after making changes, but before as well.

I've made it myself by extending Mapper class and overwriting the "flushSingle" method. It would be a nice feature to Relational.

---

Thinking about other frameworks... maybe forcing an event dispatcher interface wouldn't be nice, since some uses "on", others use "addEventListener", some uses "emit" and others "dispatch", some uses events as method-names (and even Interfaces for listeners/dispatchers) and others strings for identifying them...

[nawarian]

Ping...

[henriquemoody]

I'm sorry by my late.

I was thinking about it, there are many reasons to do inside the library.

As @williamespindola already said, there are many things we can do using an external event dispatcher, but it depends of what you want to do; if you want to make some profiling, for example, or just perform an action after every flush, wrapping everything will be a PITA.

I think it can be really useful but I have no concrete idea about how it should be done inside Relational.

Actually, TBH, I'm not sure what should be done in Relational and what should be make in Data, since it was splitted Relational.

@nawarian, I'm really receptive for any pull request you want to send, I can also make some code review of it but I probably will not do this feature, despite I think it's a great idea.

[williamespindola]

My concern is. I think that Respect\Relational is not a large lib like Doctrine but have a Power like Doctrine. If we take a look Data, DB, Sql are modules, and following this thought Events must be too.