I currently have a model structure as follows:
/**
* #ORM\Entity
* #ORM\InheritanceType("JOINED")
* #ORM\DiscriminatorColumn(name="related_type", type="string")
* #ORM\DiscriminatorMap({"type_one"="TypeOne", "type_two"="TypeTwo"})
*/
abstract class BaseEntity {
... (all the usual stuff, IDs, etc)
/**
* #ORM\OneToMany(targetEntity="Comment", mappedBy="baseEntity")
*/
private $comments;
}
/**
* #ORM\Entity
*/
class TypeOne extends BaseEntity {
/**
* #ORM\Column(type="string")
*/
private $name;
/**
* #ORM\Column(type="string")
*/
private $description;
}
/**
* #ORM\Entity
*/
class TypeTwo extends BaseEntity {
/**
* #ORM\Column(type="string")
*/
private $name;
/**
* #ORM\Column(type="string")
*/
private $description;
}
/**
* #ORM\Entity
*/
class Comment {
... (all the usual stuff, IDs, etc)
/**
* #ORM\ManyToOne(targetEntity="BaseEntity", inversedBy="comments")
*/
private $baseEntity;
}
The idea here is to be able to tie a comment to any of the other tables. This all seems to be working ok so far (granted, I'm still exploring design options so there could be a better way to do this...), but the one thing I've noticed is that the subclasses have some common fields that I'd like to move into a common parent class. I don't want to move them up into the BaseEntity as there will be other objects that are children of BaseEntity, but that won't have those fields.
I've considered creating a MappedSuperclass parent class in the middle, like so:
/**
* #ORM\MappedSuperclass
*/
abstract class Common extends BaseEntity {
/**
* #ORM\Column(type="string")
*/
private $name;
/**
* #ORM\Column(type="string")
*/
private $description;
}
/**
* #ORM\Entity
*/
class TypeOne extends Common {}
/**
* #ORM\Entity
*/
class TypeTwo extends Common {}
I figured this would work, but the doctrine database schema generator is complaining that I can't have a OneToMany mapping on a MappedSuperclass. I didn't expect this to be a problem as the OneToMany mapping is still between the root BaseEntity and the Comment table. Is there a different structure I should be using, or other way to make these fields common without adding them on the BaseEntity?
From the Docs:
A mapped superclass is an abstract or concrete class that provides
persistent entity state and mapping information for its subclasses,
but which is not itself an entity. Typically, the purpose of such a
mapped superclass is to define state and mapping information that is
common to multiple entity classes.
That said, how can you associate one entity with one that is not?
More from the docs:
A mapped superclass cannot be an entity, it is not query-able and
persistent relationships defined by a mapped superclass must be
unidirectional (with an owning side only). This means that One-To-Many
assocations are not possible on a mapped superclass at all.
Furthermore Many-To-Many associations are only possible if the mapped
superclass is only used in exactly one entity at the moment. For
further support of inheritance, the single or joined table inheritance
features have to be used.
Source: http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/inheritance-mapping.html
Update
Because your MappedSuperClass extends BaseEntity it also inherits the BaseEntity's associations, as if it were its own. So you effectively DO have a OneToMany on a MappedSuperClass.
To get around it, well, you'd need to modify/extend doctrine to work the way you want.
As far as native functionality goes you have two options:
Class Table Inheritance
You Common class and the resulting DB representation would have the common fields and child classes will now only have the fields specific to themselves. Unfortunately this may be a misrepresentation of your data if you are simply trying to group common fields for the sake of grouping them.
Make Common an Entity
It appears that all a Mapped Super Class is is an Entity that isn't represented in the DB. So, make common a Entity instead. The downside is that you'll end up with a DB table, but you could just delete that.
I recommend that you take a second look at your data and ensure that you are only grouping fields if they are common in both name and purpose. For example, a ComputerBox, a ShoeBox, a Man, and a Woman may all have the "height" property but in that case I wouldn't suggest have a Common class with a "height" property that they all inherit from. Instead, I would have a Box with fields common to ComputerBox and ShoeBox and I'd have a Person with fields common to Man and Woman. In that situation Class Table Inheritance or single table if you prefer would work perfectly.
If your data follows that example go with Single Table or Class Table Inheritance. If not, I might advise not grouping the fields.
Related
I am using the FOSUserBundle in order to manage my users into my application.
But in fact, I have multiple user entities: ParticularConsumer.php and ProfessionnalConsumer.php. So I create a ParentUser.php entity who as an abstract class who extends BaseUser of FOSUserBundle. See the code here:
/**
* ParentUser
*
* #ORM\Table(name="parent_users")
* #ORM\InheritanceType("JOINED")
* #ORM\DiscriminatorColumn(name="discr", type="string")
* #ORM\DiscriminatorMap({"particular_consumer" = "ParticularConsumer", "professionnal_consumer" = "ProfessionnalConsumer"})
* #ORM\Entity(repositoryClass="MyBundle\EntityBundle\Repository\ParentUserRepository")
*
*/
abstract class ParentUser extends BaseUser
{
/**
* #ORM\Id
* #ORM\Column(name="pusr_id", type="integer", nullable=false)
* #ORM\GeneratedValue(strategy="AUTO")
*/
protected $id;
public function __construct()
{
parent::__construct();
// your own logic
}
// ...
So there are the two other entities who extend the Parentuser.php, following the Class Table Inheritance of Doctrine behavior and documentation:
First ParticularConsumer.php
/**
* ParticularConsumer
*
* #ORM\Table(name="particular_consumer")
* #ORM\Entity(repositoryClass="MyBundle\EntityBundle\Repository\ParticularConsumerRepository")
*
*/
class ParticularConsumer extends ParentUser
{
public function __construct()
{
parent::__construct();
// your own logic
}
}
Second ProfessionnalConsumer.php
/**
* ProfessionnalConsumer
*
* #ORM\Table(name="professionnal_consumer")
* #ORM\Entity(repositoryClass="MyBundle\EntityBundle\Repository\ProfessionnalConsumerRepository")
*
*/
class ProfessionnalConsumer extends ParentUser
{
public function __construct()
{
parent::__construct();
// your own logic
}
}
Now, that I would like to do and to know is how to persist the parent and child entities.
Indeed, as I use the FOSUserBundle, all the routes (register,login, etc...) are managed and generated by this bundle. Now I need to persist datas in Child entities, normally it persists datas in parent entity, that's right ? How can I proceed exactly ?
This how I need to proceed to register a consumer:
There is a question on a page, whish ask users if there are
professionals or particulars.
A drop down list is here for them to make the choice.
Following the choice, I need to register the user in the right entity.
If the user choose particular in the drop down list, I need to
load/display a form to persist data in ParticularConsumer.php and not only in ParentUser.php.
But as I use the FOSUSerBundle, I don't really know how to proceed exactly. As you can understand, using the FOS is a practical way in order to manage users and manage the security, I would like to keep the logic of the bundle. And I want to use the good practices.
Finally, following all the doc of the FOSUserBundle in order to install it, if I want to register a user (localhost/web/app_dev.php/register) I have this error:
Error: Cannot instantiate abstract class MyBundle\EntityBundle\Entity\ParentUser
If your ParentUser is an abstract class then it cannot be an Entity. In such case you have to make it to a MappedSuperClass. But as you can read in the documentation:
A mapped superclass cannot be an entity, it is not query-able and persistent relationships defined by a mapped superclass must be unidirectional (with an owning side only). This means that One-To-Many associations are not possible on a mapped superclass at all. Furthermore Many-To-Many associations are only possible if the mapped superclass is only used in exactly one entity at the moment. For further support of inheritance, the single or joined table inheritance features have to be used.
If you want to be able to query your ParentUser and you want this class to have its own entity repository then you will have to remove abstract and add a value for ParentUser to your #ORM\DiscriminatorMap definition:
#ORM\DiscriminatorMap({
"parent_user" = "ParentUser"
"particular_consumer" = "ParticularConsumer",
"professionnal_consumer" = "ProfessionnalConsumer"
})
I have four types of products which I would like to map to a Doctrine ORM structure on a MySQL RDBMS. The products are PrepaidProduct, PostpaidProduct, MobilePrepaidProduct, MobilePostpaidProduct with the following structure:
abstract class Product {
/**
* #ORM\Column(type="integer")
*/
private $price;
...
}
class PrepaidProduct extends Product {
/**
* #ORM\Column(type="integer")
*/
private $credit;
/**
* #ORM\OneToMany(targetEntity="PrepaidDiscount")
*/
private $prepaidDiscounts;
}
class PostpaidProduct extends Product {
/**
* #ORM\OneToMany(targetEntity="BundleMapping")
*/
private $bundleMappings;
}
class MobilePrepaidProduct extends PrepaidProduct {
/**
* #ORM\ManyToOne(targetEntity="Device")
*/
private $device;
}
class MobilePostpaidProduct extends PostpaidProduct {
/**
* #ORM\ManyToOne(targetEntity="Device")
*/
private $device;
}
The main idea is that I would like to use a service (factory) that will use the basic class structure of the PostpaidProduct class to create a structure of the corresponding bundle mapping, so I think I would need this as a mapped super class.
In my opinion the way to go would be to have two separate tables, one for PostpaidProduct and one for PrepaidProduct, and have a Single Table Inheritance on those for MobilePostpaidProduct/PostpaidProduct and MobilePrepaidProduct/PrepaidProduct.
What do you guys think? Any thoughts on best way to model this?
If you are using a RDBMS layer [MySQL, Postgre] as I think, your proposal is the best choice in my opinion.
If subclasses have *little more attributes, possibly relationships most of all, you are actually promoting composition and your data representation won't be sparse [i.e. you won't have many empty fields in the main table].
On the other hand, if you want to stick with composition only [which is more advisable in most cases] - is $device the only additional relationship in Mobile classes? If so, you could write a findAllMobileProducts method in your repository class that would return every product where device is not null, and so on.
I am not very good at asking questions but the code below should be self-explanatory.
I need to create a OneToOne association from a class to an entity's superclass which is NOT an entity.
/* Not an entity */
class Superclass {
/**
*#Id #Column(name="entity_id", type="integer") #GeneratedValue
**/
protected $id;
}
/**
* #Entity #Table(name="subclasses1")
**/
class Subclass1 extends Superclass {
}
/**
* #Entity #Table(name="subclasses2")
**/
class Subclass2 extends Superclass {
}
/**
* #Entity #Table(name="assoc")
**/
class Associationclass
{
/**
*OneToOne(targetEntity="Superclass")
**/
protected $association;
/**
*#Column(type="string")
**/
protected $info;
}
The question is: How can I reference both subclass1 and subclass2 using the OneToOne relationship without making Superclass an Entity (creating a new table and using discriminators)?
You can't. If you want that sort of inheritance (the kind you can use in associations), you need to model the inheritance in doctrine.
The association needs a "targetEntity" -- which, like the name indicates, must be an entity.
Unless there's a very good reason not to, go ahead and make your superclass an entity, and set up the inheritance in a way doctrine can understand.
The reason your superclass needs to be an entity is because the superclass and it's subclasses will then share an identifier. So with the identifier (and the discriminator), doctrine can then figure out that SuperClass#1234 is actually a SubClass2.
as pointed out here: Doctrine 2.1 - Map entity to multiple tables Doctrine2 does not allow mapping of one object to multiple tables.
I currently have a Mysql db setup similar to this:
base_entity: id, some_basic_data_columns
state: id, state, entity_id (FK to base_entity.id), start_time, end_time, ...
entity_one: id (FK to base_entity.id), some_specific_data
entity_two: id (FK to base_entity.id), some_specific_data
and so on...
In a way, entity_x is "extending" base_entity, and all these entities can have multiple states. To have proper foreign keys I would have to either have separate state tables (which I don't want to do because they will structurally be the same ), or do it like this.
The base entity by itself is useless, id could even be boiled down to just the id field to allow to join with each child entity to multiple states.
I do not need a BaseEntity class, but I do need for each child Entity to have a getStates() method. Of course I may actually have an abstract entity class, but concrete entities will extend it, not have it as a property like they would if I would map them as one would map other one-to-one relationships
Since Doctrine will not allow me to map EntityOne to both entity_one and base_entity table I have to ask:
Is this bad design? Am I overlooking some other way to solve this elegantly? I know other DMBSs have inheritance, but for instance PostgreSql would still not allow me to join the base_entity to state if no physical base_entity exists for a child.
I could do something like this on the code side:
class EntityOne {
// baseEntity as a property
private $_baseEntity;
// private getter for the base table
private getBaseEntity();
// and getters like this for properties in the base table
public getStates(){
return $this->getBaseEntity()->getStates();
}
}
This way the entity would behave like a single entity (not combined from base and child) to the outside world, but it would still require that I write a separate BaseEntity class and all the config info to connect it to other entity classes
Basically, what I'm asking is: is this a Db design issue, and I got it completely wrong from the start (and if I did, which is the "best" approach), or is this a code issue, and I should work around it with code (if so, is my approach in 2. ok, or are there better ways to deal with this), and are there ORMs which allow for multiple table mapping?
Many thanks in advance.
You could use Class Table Inheritance (see Doctrine documentation about that), defining a BaseEntity entity class, and and create EntityOne and EntityTwo extending that.
You could define the relationship between the BaseEntity class and the State entity class as one-to-many association - if I understood right what you wanted, providing the needed getState() method in the BaseEntity class.
Something like this:
/**
* #Entity
* #Table(name="base_entity")
* #InheritanceType("JOINED")
* #DiscriminatorColumn(name="entity_type", type="string")
* #DiscriminatorMap({"entity_one"="EntityOne", "entity_two"="EntityTwo"})
*/
class BaseEntity {
/**
* #Id
* #Column(type="integer")
*/
protected $id;
/**
* #OneToMany(targetEntity="State", mappedBy="entity)
**/
protected $states;
public function getStates() {
return $this->states;
}
...
}
/**
* #Entity
* #Table(name="entity_one")
*/
class EntityOne extends BaseEntity {
...
}
/**
* #Entity
* #Table(name="entity_two")
*/
class EntityTwo extends BaseEntity {
...
}
/**
* #Entity
* #Table(name="state")
*/
class State {
/**
* #ManyToOne(targetEntity="BaseEntity", inversedBy="states")
* #JoinColum(name="entity_id", referencedColumnName="id")
*/
protected $entity;
public function getEntity() {
return $this->entity;
}
...
}
How do I create traditional polymorphic relationships with Doctrine 2?
I have read a lot of answers that suggest using Single Table Inheritance but I can't see how this would help in my situation. Here's what I'm trying to do:
I have some utility entities, like an Address, an Email and a PhoneNumber.
I have some 'contactable' entities, like a Customer, Employer, Business. Each of these should contain a OneToMany relationship with the above utility entities.
Ideally, I'd like to create an abstract base class called 'ContactableEntity' that contains these relationships, but I know it is not possible to put OneToMany relationships in mapped superclasses with doctrine-- that's fine.
However, I am still at a loss at how I can relate these without massive redundancy in code. Do I make Address an STI type, with a 'CustomerAddress' subclass that contains the relationship directly to a Customer? Is there no way to reduce the amount of repetition?
Why not just make your base ContactableEntity concrete?
EDIT:
Just did a few experiments in a project I've done that uses CTI. I don't see any reason that the same strategy wouldn't work with STI.
Basically, I have something like:
/**
* Base class for orders. Actual orders are some subclass of order.
*
* #Entity
* #Table(name="OOrder")
* #InheritanceType("JOINED")
* #DiscriminatorColumn(name="discr", type="string")
* #DiscriminatorMap({"CAOrder" = "CAOrder", "AmazonOrder" = "AmazonOrder"})
*/
abstract class Order {
/**
* CSRs can add notes to orders of any type
* #OneToMany(targetEntity = "OrderNote", mappedBy = "order", cascade={"all"})
* #OrderBy({"created" = "ASC"})
*/
protected $notes;
// ...
}
/**
* #Entity
*/
class AmazonOrder extends Order {
/**
* #Column(type="string", length="20")
*/
protected $amazonOrderId;
// ...
}
/**
* #Entity
*/
class OrderNote {
// ...
/**
* #ManyToOne(targetEntity="Order", inversedBy="notes")
*/
protected $order;
// ...
}
And it seems to work exactly as expected. I can get an OrderNote, and it's $order property will contain some subclass of Order.
Is there some restriction on using STI that makes this not possible for you? If so, I'd suggest moving to CTI. But I can't imagine why this wouldn't work with STI.
If the contactable entity shall be abstract (#MappedSuperclass) you'll need to use the ResolveTargetEntityListener provided by Doctrine 2.2+.
It basically allows you to define a relationship by specifying an interface instead of a concrete entity. (Maybe you want to define/inherit several interfaces as you speak of multiple "contactables"). For instance you then can implement the interface in your abstract class or concrete class. Finally you'll need to define/associate the concrete class (entity) to the related interface within the config.yml
An example can be found in the Symfony docs: http://symfony.com/doc/current/cookbook/doctrine/resolve_target_entity.html