Support mapping of entry data to database columns

[ryanmitchell]

This is a WIP.

This PR makes it possible to store the contents of data handles in alternative columns in your database, eg you may want to store my_key in a column called my_column.

The benefit of this is it allows you to index that column separately which can speed up database operations.

Mapping can be added by adding a hook on the eloquent entry class, and updating the array $payload. This array is a mapping of data handles to database columns (note that only root-level data keys are supported).

        Entry::hook('data-column-mappings', function (array $payload, $next) {
            $payload = array_merge($payload, ['my_key' => 'my_column']);

			return $next($payload);
        });

Closes https://github.com/statamic/eloquent-driver/issues/272

[ryanmitchell]

@duncanmcclean @jasonvarga would appreciate your thoughts on this when you get a chance.

[jasonvarga]

The statamic-5 branch has been merged, so this PR should target master.

[duncanmcclean]

Mapping can be added by adding a hook on the eloquent entry class, and updating the array $payload. This array is a mapping of data handles to database columns (note that only root-level data keys are supported).

Just thinking out loud here.... instead of mapping the columns using a hook, is there any way the Eloquent Driver could figure out those columns itself, based on the columns in the database?

Maybe it could get a list of the model's columns, filters out columns that already get mapped (like slug, data, updated_at, etc), then use the columns that are left to read/write fields from?

[ryanmitchell]

It could, but that would mean an extra query every time to get the columns. Not a hugely expensive operation but worth considering. It also limits us to root keys only - the current mapping approach could quite easily be extended to allow non-root keys.