Framework: Observer priority

[deviouspk]

As of laravel 5.4 the parameter $priority does not exist on the model::observe() method anymore.

How do we prioritize observers?

[bhulsman]

Seems to be intentionally removed, doesn't say why: https://github.com/laravel/framework/pull/17303

[erdemkeren]

From the official docs (https://laravel.com/docs/5.4/upgrade):

Event Priority

Support for event handler "priorities" has been removed. This undocumented feature typically indicates an abuse of the event feature. Instead, consider using a series of synchronous method calls. Alternatively, you may dispatch a new event from within the handler of another event in order to ensure that a given event's handler fires after an unrelated handler.

[deviouspk]

Hmm,
I'm writing a generic Schema validator Observer that validates the model before it gets saved to the database (using mongodb so it does not have any predefined schema).

But in order to do that i need to make sure that the events that the observer triggers will be the last ones to be fired. For example another observer could modify the data first so that the schema suddenly becomes valid. But that wouldn't work when the SchemaValidatorObserver gets executed first.

I'm not sure how to implement that with the advice from taylor:

Event Priority

Consider using a series of synchronous method calls. Alternatively, you may dispatch a new event from within the handler of another event in order to ensure that a given event's handler fires after an unrelated handler.

[erdemkeren]

Validating model data consistency with observers looks weird to me. If I were you, I would consider trying another way around, something which is more reliable. Something not breakable by other functionalities or events.

[deviouspk]

It’s not weird at all. It’s the last place in laravel before data gets written away to the database (apart from overriding eloquent methods).For the project im currently working on it is crucial that no invalid data goes into the database (working with states).

[mfn]

For example another observer could modify the data first so that the schema suddenly becomes valid.

I assume you are in control of all the observers running. In that case, you can make a single observer _for your_ application and use a customized observer within, guaranteeing your execution order.

Or you could override save()

Or you could override the the Builders insert and update methods.

I think eventually you've to come up with your own solution as priorities are not coming back.

[erdemkeren]

Because of the intentional removal of the feature you were using, I don't want to discuss at length here.

To explain my thoughts better:
I understand your perspective. However, in general, events keep track of interesting things happen in unpredictable times like a button click, a timer expiration or a change in file system. Like $('#button').click(). But you say that you need to make sure that the events that the observer triggers will be the last ones to be fired. That looks like an abuse to me.

Best wishes!

[deviouspk]

I assume you are in control of all the observers running. In that case, you can make a single observer for your application and use a customized observer within, guaranteeing your execution order.

Well partly i made an api framework that i reuse for multiple projects. So i kinda prefer keeping this validation part in the main framework so that all the subprojects that stay in sync with it and work the same way.
Overriding is indeed a possibility.

@erdemkeren
I obviously see where you're going to but this is not how the observers in laravel behave. I know it's being fired as an event. But the handlers for an event (=observers here) shouldn't be able to interfere with the logic that's coming after it and should always be able to be processed async. But observers cannot be processed async and do interfere with the logic that follows. see the following example:

This code will prevent eloquent from saving the model to the database.
So taking that into account i really don't consider it an abuse.

[laurencei]

I'll be closing this, as it is clear the feature was intentionally removed from the framework by Taylor and is not a bug.