doctrine - single table inheritance and native query fails - doctrine-orm

Question

In a symfony 2.8 app I have following class hierarchy configured as single table inheritance:
parent: App\Entity\AbstractUser
child1: App\Entity\UserClient
child2: App\Entity\UserGuest
Further each class from above has a oneToOne relation to a class App\Entity\Profile.
Based on the above I have a native query on the profiles table joining the users table.
The goal is to get the profile data together with the related user data in one query.
It did work for a while but stopped working at some point. Probably after doctrine bundle update.
Now my code below throws the following exception: The provided class "App\Entity\AbstractUser" is abstract, and can not be instantiated.
What can I do to make it work again?
Here is my code:
$rsm = new ResultSetMapping;
$rsm->addEntityResult('App\Entity\AbstractUser', 'br');
$rsm->addFieldResult('br', 'user_id', 'id');
$sql = "
SELECT
rsa.id AS profile_id,
br.id AS user_id
FROM profiles rsa
LEFT OUTER JOIN users br ON rsa.id = br.profile_id
";
try {
$query = $this->_em->createNativeQuery($sql, $rsm);
$results = $query->getResult();
} catch (\Exception $e) {
throw $e;
}
Here are the doctrine definitions:
// Resources/config/doctrine/AbstractUser.orm.yml
App\Entity\AbstractUser:
type: entity
table: users
inheritanceType: SINGLE_TABLE
discriminatorColumn:
name: type
type: string
length: 30
nullable: false
discriminatorMap:
client: App\Entity\UserClient
guest: App\Entity\UserGuest
fields:
id:
id: true
type: integer
generator:
strategy: AUTO
# oneToOne association
oneToOne:
profile:
targetEntity: App\Entity\Profile
cascade: ['persist','remove']
joinColumn:
name: profile_id
referencedColumnName: id
nullable: false
unique: false
// Resources/config/doctrine/UserClient.orm.yml
App\Entity\UserClient:
type: entity
// Resources/config/doctrine/UserGuest.orm.yml
App\Entity\UserGuest:
type: entity
// Resources/config/doctrine/Profile.orm.yml
App\Entity\Profile:
type: entity
table: profiles
fields:
id:
id: true
type: integer
generator:
strategy: AUTO

Answer 1

You should be using either of:
DiscriminatorMap (Single or Class Table Inheritance)
MappedSuperclass
Info on both here
MappedSuperclass
This is similar to PHP's abstract class. You can not instantiate this class. It is therefore a class which must be extended into something proper. As such you could have:
AbstractUser
Guest extends AbstractUser
Admin extends AbstractUser
This would give you a few things:
Some properties and functions are available for both (saves duplicate code - DRY)
Gives the same "parent" class as an instance
Setup & use case
/**
* #ORM\MappedSuperclass
*/
abstract class AbstractEntity
{
/**
* #var int
* #ORM\Id
* #ORM\Column(name="id", type="integer", options={"unsigned":true})
* #ORM\GeneratedValue(strategy="IDENTITY")
*/
protected $id;
// getter / setter
}
This use case shows the usage of a common identifier for all entities in my own projects. It also gives an easy entry-point to validate whether or not a specific Entity is in my own projects or supplied by a vendor, doing:
if ($entity instanceof AbstractEntity) { ... }
Single / Class Table Inheritance
Now, let's use the MappedSuperclass in Table Inheritance. We're going with the JOINED strategy in this example, but feel free to use whichever suits your needs best.
You have 3 classes, 2 of which are instantiable:
UserClient
UserGuest
Both stem from: AbstractUser
Now, let's say that "Guest" is the most limited user, we'll create that one first:
/**
* #ORM\Entity
* #ORM\Table(name="user_guests")
*/
class Guest extends AbstractEntity
{
/**
* #var string
* #ORM\Column(name="display_name", type="string", length=255, nullable=false)
*/
protected $displayName;
/**
* #var string
* #ORM\Column(name="email", type="string", length=255, nullable=false, unique=true)
*/
protected $email;
/**
* #var string
* #ORM\Column(name="password", type="text", nullable=false)
*/
protected $password;
// getters / setters
}
So far so good.
Now, we have the need to create "Client". A client should have:
displayName
email
password
clientId
The first 3 are the same as for Guest. So, it might be wise to extend Guest. Will other things (e.g. functionality) be the same for either user type? Such as:
way of logging in/out
being an email recipient/sender
etc.
If a lot of these use cases are the same, then we have a solid case for using Table Inheritance. So, update the Annotation for Guest, like so:
/**
* #ORM\Entity
* #ORM\Table(name="user_guests")
*
* #InheritanceType("JOINED")
* #DiscriminatorColumn(name="discr", type="string")
*/
class Guest extends AbstractEntity { ... }
NOTE: We do not declare a DiscriminatorMap. Doctrine will handle this for us. Per the docs:
If no discriminator map is provided, then the map is generated automatically. The automatically generated discriminator map contains the lowercase short name of each class as key.
Next, create the Client:
/**
* #ORM\Entity
* #ORM\Table(name="user_clients")
*/
class Client extends Guest
{
/**
* #var string
* #ORM\Column(name="client_id", type="string", length=50, nullable=false)
*/
protected $clientId;
// getters / setters
}
The SQL generated by Doctrine for these 2, as an example, is this:
CREATE TABLE user_guests
(
id INT UNSIGNED AUTO_INCREMENT NOT NULL,
display_name VARCHAR(255) NOT NULL,
email VARCHAR(255) NOT NULL,
password LONGTEXT NOT NULL,
discr VARCHAR(255) NOT NULL,
UNIQUE INDEX UNIQ_2843A78FE7927C74 (email),
PRIMARY KEY (id)
) DEFAULT CHARACTER SET utf8
COLLATE utf8_unicode_ci
ENGINE = InnoDB;
CREATE TABLE user_clients
(
id INT UNSIGNED NOT NULL,
client_id VARCHAR(50) NOT NULL,
PRIMARY KEY (id)
) DEFAULT CHARACTER SET utf8
COLLATE utf8_unicode_ci
ENGINE = InnoDB;
ALTER TABLE user_clients
ADD CONSTRAINT FK_58C5307EBF396750 FOREIGN KEY (id) REFERENCES user_guests (id) ON DELETE CASCADE;
Shown visually, that's:
Now you can also add in your Profile Entity very easily. You simply add it to your Guest user, with a OneToOne bi-directional relation.
So, add to your Guest:
// other properties
/**
* #var Profile
* #ORM\OneToOne(targetEntity="Profile", cascade={"persist", "remove"}, fetch="EAGER", inversedBy="Guest")
* #ORM\JoinColumn(name="profile_id", referencedColumnName="id")
*/
protected $profile;
// getter / setter
At this point though, you might wish to consider renaming "Guest" to plain "User", as using that for a name could be less confusing in the future. "User" is usually already a pretty limited member, similar to a Guest (the difference usually being that a "Guest" is not a registered User and a User is).
Now you can simply do:
$profile->getGuest() // or ->getUser() if you renamed
// Returns instance of Guest (might be child instance: Client)
$guest->getProfile() // returns Profile
$client->getProfile() // returns Profile
$user = new Guest();
$user instanceof Guest ? true : false; // true
$user instanceof Client ? true : false; // false
$user = new Client();
$user instanceof Guest ? true : false; // true
$user instanceof Client ? true : false; // true