very interesting, I'm going to implement it as well

I've changed something

public function save(array $options = array())
{
    if ($this->subclassField) {
        $this->attributes[$this->subclassField] = get_class($this);
    }

    return parent::save($options); // return boolean
}

In my project I check if the model is saved buy doing something like

$image = $this->image->newInstance();
$image->name = 'test image';

return $image->save() ? $image : null;

By returning parent::save($options) I can check if the save went ok

@zenry

I agree that the parent::save() should be returned. This is something that I've since implemented as well. I've updated the original post to reflect the change.

This is a really neat idea. With a side project I'm working on I might look at using this approach. I'll have a whole bunch of incidents, such as fire, car accident, flood, etc. Single Table Inheritance should make this a whole lot easier.

I'm looking into using STI for my users table. I'm using Sentry and have 9 different user groups, and my User model is becoming obscene with all logic required for different types of users. This way I can have a base User class, and then either have a class for each user group, or a few different classes to represent similar user groups.

Regarding adding nullable columns: I completely agree. Although, if your data starts to change over time (i.e. in the case of different user groups, maybe new fields are required only for a subset of the groups) you can split it up into another table (i.e. admin_user_profile, member_user_profile).

Seems to be working well. I just wanted to share one change I made:

public function newQuery($excludeDeleted = true)
{
    $builder = parent::newQuery($excludeDeleted);

    // if this is a subclass, add the subclass field to the query
    if ($this->subclassField && $this->isSubclass()) {
        $builder->where($this->subclassField, '=', get_class($this));
    }

    return $builder;
}

It looked like the only change to the newQuery function was adding in the where clause for the subclassField, so I just have it call the parent method, and then customize the returned builder and return it. This also helps remove the L4.0/L4.1 check mentioned in the comments.

Please let me know if anyone sees any issues with this.

Sorry to resurrect an old thread; I wanted to mention that I found this very helpful, but in t removed the whole $isSubclass approach, and replaced the function with the following:

public function isSubclass()
{
   return (get_parent_class($this) != self::class && is_subclass_of($this,self::class));
}

In my testing so far, this seems to work well regardless of what I name the abstract class, and doesn't require a specific variable in each of my subclass models.

That said, let me know if there are issues with this approach that I may not have encountered yet.

ryanabrams change works just fine, in PHP <= 5.4 you have to use CLASS instead of self::class though.

    public function isSubclass()
    {
        return (
            get_parent_class($this) != __CLASS__
            && is_subclass_of($this, __CLASS__)
        );
    }