But... call_user_func()? Or what?

I had not found how to actually do that.

It is not, same as below.

A unique constraint may cause an index to be created, but it is a different type of index -- because it can't help you speed up queries by hitting the right index in the right way.

No, my reading habits do -- I read vertical space used much, much faster than horizontal space.

We can change it further when we have switched over most if not all tests to using volatile fixtures and not seeded contents, and split up multiple test functions per test class such that there's only one series of tests per class (currently all test functions assert the same start state).

$object->senderPolicyFrameworkWhitelist($data['client_name']) ? ;)

I've found it could be done per route like this Route::group(['prefix' => 'api', 'middleware' => 'throttle:3,10'], function () { or probably just create a seaparate middleware label for these heavy APIs. https://laravel.com/docs/6.x/middleware#assigning-middleware-to-routes

They are the same.

$table->unique(
	        ['sender_local', 'sender_domain', 'recipient_hash', 'net_id', 'net_type'],
	         'ssrnn_unq'
 );

I'll trust you know better in this case, but I always thought that unique index is used as any other index. Why not?

In my eyes this creates a mess right now. Isn't that breaking any existing tests?

Of course. I complete overlooked that.

I reckon too that our internal infrastructure is not supposed to be limited at this level, at all.

A unique index is a constraint that incidentally uses an index in order to speed up the lookup to pass or fail on a unique constraint.

For example, a unique constraint could simply exist of a single column using a hash over cells appended to one another. It doesn't concern itself with comparison or range lookups, can completely ignore column types and is as such, when implemented correctly (so as to be most efficient as a unique constrained) in a database technology, it isn't an index you'd likely hit with a query so as to get to a resulting row.

Existing tests either use seeded content or set themselves up with a per-test domain/users/etc.

In dev/testing though, all tests are intended to use one single set of 'fixtures' -- however many of those there may be, and in however many "sets" we may break them down so as to make tests run more efficiently, and to whichever extent we may indeed refactor tests such that fixtures setup and teardown can happen once per class rather than once per test.