@crynobone You may create related models like this (if that is what you mean?):

$user->latest_login()->create();

This will create the related model, but in some cases the model is incorrectly set as a relation. Given the case first_login, the newly created login is not the first login. Therefore, relations should always be created via the associated one-to-many relation (this would be logins in this case).

This seem to be read-only (SELECT query) feature, or is it possible to associate relationship using oneOfMany? If so how would that work?

@taylorotwell The test was indeed missing the required mocks to get resolve the connection. The test was only passing before because a previous test binded a connection resolver to the Model class. The new test case DatabaseEloquentMorphOneOfManyTest overrided the connection resolver again which resultet in the test to fail. I fixed it by adding the required mocks to the failing test.

I got the required mocks from the DatabaseEloquentModelTest test case.

Just adding another comment from me in favor of merging this:

Currently working on an ecommerce project where we need to keep track of price changes (regulatory requirements etc), and statuses of orders. With timestamps of everything etc. Currently the solution I have come up with is using spatie/laravel-activitylog to keep track of the model changes. Processing here though would require alot more processing than doing this approach, which also seems much more elegant to keep track of changes like these.

I see the part where this adds alot of code to maintain, and that changes to eloquent are major, but these are one of the changes that will help writing apps with powerful features, easier! If there is one PR I have seen in the latest timespan that should be merged, it is this one!

@mfn I can see where you're coming from, but I think your last test is a feature and not a bug. Perhaps if you rename this to "strict attributes" (as opposed to strict relationships) you can see how getting a fatal error is desired if I forget to add a column in my select statement.

@mfn I can see where you're coming from, but I think your last test is a feature and not a bug. Perhaps if you rename this to "strict attributes" (as opposed to strict relationships) you can see how getting a fatal error is desired if I forget to add a column in my select statement.

Wow, I know there cases Where I could use it immediately.

@tomirons Can you clarify the issue you face? Which changes did you try? I've used something similar in one of my projects and it's working fine. I might write a blog post on how to do this in a project if this doesn't get merged.

I do this manually often, especially since learning how to do it elegantly from @reinink. I’ve helped multiple clients do it as well, one within the last few weeks. This would be a very welcome addition

@taylorotwell We need this in framework itself ASAP. Thanks!

@taylorotwell I think the failing test is not related to the pr. I wonder why the test wasn't failing before. The method getConnection gets called which requires the connection to be set in the config which it isn't. Shouldn't this be set up before?

    public function testPropertiesAreSetCorrectly()
    {
        $parent = m::mock(Model::class.'[getConnectionName]');
        $parent->shouldReceive('getConnectionName')->twice()->andReturn('connection');
        $parent->getConnection()->getQueryGrammar()->shouldReceive('getDateFormat')->andReturn('Y-m-d H:i:s');
        $parent->setDateFormat('Y-m-d H:i:s');
        $pivot = Pivot::fromAttributes($parent, ['foo' => 'bar', 'created_at' => '2015-09-12'], 'table', true);

        $this->assertEquals(['foo' => 'bar', 'created_at' => '2015-09-12 00:00:00'], $pivot->getAttributes());
        $this->assertSame('connection', $pivot->getConnectionName());
        $this->assertSame('table', $pivot->getTable());
        $this->assertTrue($pivot->exists);
    }

(link to test)

The DatabaseEloquentPivotTest is failing. Any ideas why? 🤔

Tests seem to be failing?

I implemented the feature to the morph-one relationship as well.

3 abstract methods where added to the trait:

1. addJoinSubConstraints(JoinClause $join) - Adds constraints to the joins clause.
2. getGroups() - Gets the columns the determine the relationship groups.
3. addSubQueryConstraints - Adds constraints to the subselect.

Tests for the morph-one implementation can be found in the DatabaseEloquentMorphOneOfManyTest test case:

https://github.com/laravel/framework/blob/a81c9a58118c5b4ef4194eb2b4f950242a7ff07c/tests/Database/DatabaseEloquentMorphOneOfManyTest.php#L58-L110

I think this is an extremely useful feature to have in the framework itself. In all projects I have done there has been some sort of status usage on the models, and with this approach it would be very useful to track the changes.

The examples are also perfect use cases where inner joins is a very valid solution.

I am casting a vote to merge this PR as part of the framework.

I will remove the method and implement the code shown above. I did not want to implement it right away in case there are objections 😅

So, if the method is not needed - what should I do? :)

How would this be ported to support MorphOne as well?

The query would look like this:

SELECT *
FROM `states`
INNER JOIN (
    SELECT MAX(id) AS id
    FROM states
    GROUP BY states.stateful_id, states.stateful_type,
) AS state 
ON state.id = states.id

For examples that do not have the key as aggregate, the morph id and type need bo added to the ON constraints:

...
INNER JOIN (
    SELECT MAX(foo) AS foo
    ...
    GROUP BY states.stateful_id, states.stateful_type,
) AS state 
ON state.foo = states.foo AND state.stateful_id = states.stateful_id AND state.stateful_type = states.stateful_type

To the CanBeOneOfManyTrait can be added an abstract function that builds GROUP BY for subselects and one that builds ON constraints for inner joins, so the different implementations can be built in the respective relations classes.

I've pushed up a handful of formatting fixes - removed methods that were never called at all (tests still pass when I remove them, so I assume not needed).