first of all I'd like to apologise in advance for the question title as it might not ideally explain the situation I'm dealing with. I've done some research but had no luck finding a suitable solution.
My Case:
I'm having an entity, say an Activity, which represents activities that customers on my website perform. It can be of a different type like: page_view, comment, login, purchase etc. What I'm trying to do is to assign supplemental data to each activity eg. for a comment activity supplemental data would be a comment entity, for purchase an array of product entities etc.
For now I'm simply defining activity types as constants in ActivityInterface, and then use that values to get an EntityManager instance that is capable of resolving the correct entity/entities from parameters provided in http request. This solution has many downsides and I'm not sure if that's event a right approach.
Could you guys help me out by giving me some hints or redirect me to some useful publications on how to bite that subject? Thanks.
I recommend using a Mapped Superclass like so:
/** #MappedSuperclass */
class Activity
{
/** #Id #Column(type="integer") */
protected $id;
/** #Column(type="string") */
protected $generalActivityProperty;
// ... more fields and methods
}
/** #Entity */
class Comment extends Activity
{
/** #ManyToOne(targetEntity='CommentEntity') */
private $commentEntity;
// ... more fields and methods
}
/** #Entity */
class Purchase extends Activity
{
/** #OneToMany(targetEntity='ProductAssociations') */
private $products;
// ... more fields and methods
}
This will create a single table per Class (but not for 'Activity') each containing all fields/methods defined in 'Activity' and the additional fields/methods as defined in the specific classes.
You can even query all activities by the entityManager->getRepository('Acticity')->find() e.g. and get a list of Comment, PageView etc. Objects back.
It's not tested, but you should get an idea how to do it.
You could as well use Single Table Inheritance or Class Table Inheritance. Check it out here.
But I guess in your case a Mapped Superclass should be perfect.
Related
Maybe there are already answers regarding this topic but I cannot find any information. If there are answers already, just post any links.
My question is:
I work with Symfony 2.5 and doctrine 2
A common problem I have is that I have an entity that I want to persist to different tables in the database. For this I usually create a superclass and extend it in two concrete entities that I persist to the database.
Now I have two entities deriving from the same base class. Is it possible to convert from one to another. Of course I have to persist them to the database separately.
One example. I have two classes: "quote" and "order" which are basically the same and extend the superclass "project"
/**
* #ORM\MappedSuperclass
*/
abstract class project {
/**
* #ORM\Column(type="text", nullable=true)
*/
private $description;
/**
* #ORM\ManyToOne(targetEntity="Bundle\Customer")
*/
private $customer;
/**
* #ORM\ManyToOne(targetEntity="Bundle\CustomerContact")
*/
private $customercontact;
... (getters/setters etc.)
}
class quote extends project { ... }
class order extends project { ... }
Now once a quote is confirmed I want to "convert" it to an order and keep all the base data (stored in the "project" part). Also I want to keep the quote itself so I kind of want to create a new order from the quote instead of using the "project" directly and just set a status there.
Of course I could write a constructor or something but I am searching for a way to clone that part of an object.
Maybe there is an alternative way where the class is not extended but the "project"-part is used within the class itself. Not sure but it seems to me like a lot of people could have run into such a problem already and there might be a smart solution for this kind of situation.
I'm happy with any links to docs too if applicable.
I'm working on a notification system, so I have a notification abstract class and sub-classes (forumPostNotification, privateMessageNotification, etc). They are stored using Single Table Inheritance, so they're all in one table with a discriminating field.
I would like to get all the notifications that apply to a user at once, instead of having to query each type of notification individually, however I'm not sure how to do this in DQL/symfony (it would be easy in SQL).
I believe this: (Doctrine 2: how to write a DQL select statement to search some, but not all the entities in a single table inheritance table) is similar to what I'd like to achieve, but I'm not sure how to query the abstract object. It's also not in the Entity directory, but in Entity/Notifications/Notification.php.
I'll add some code for clarification:
Notification.php
/**
* Notification Class
*#ORM\Entity
* #ORM\InheritanceType("SINGLE_TABLE")
* #ORM\DiscriminatorColumn(name="type", type="string")
* #ORM\DiscriminatorMap({
* "notification"="Notification",
* "forumPostNotification"="ForumPostNotification",
* ...
* })
* #ORM\Table(name="notification")
*/
abstract class Notification
{
/**
* #ORM\ManyToOne(targetEntity="Acme\MainBundle\Entity\User", inversedBy="notifications")
* #ORM\JoinColumn(name="user_id", referencedColumnName="id")
*/
private $user;
//...
}
ForumPostNotification.php
/**
* Forum Post Notification
* #ORM\Entity
*/
class ForumPostNotification extends Notification
{
//..
}
PrivateMessageNotification.php
/**
* Private Message Notification
* #ORM\Entity
*/
class PrivateMessageNotification extends Notification
{
//..
}
I'd like to be able to do something like this, one way or another (I understand that I can't query from Notification, since it's an abstract class. I just wrote it like this to convey what I'd like to achieve):
$notifications = $em->createQuery('
SELECT n
FROM AcmeMainBundle:Notification n
WHERE n.dateDeactivated IS NULL
ORDER BY n.dateCreated ASC
')->getResult();
we have created similar situation with orders and products. Because you can have different types of product inside one order we made one parent class Product and inherited ex. SpecialProduct, SalesProduct etc.
We were able to define a relation between Order (in your case User) and "Product" (in your case Notification), and that's all. We get every Products for the order by $order->getProducts(). The method returns us a list of well prepared products with specific classes ex
order->products[SingleProduct, SingleProduct, SingleProduct, SpecialProduct, SalesProduct, SingleProduct]
So, in conclusion. Only one thing you need to do to get all notifications per user is defining a proper relation between your user and abstract parent class.
It was simply, but... it's not so good when you're going to get only notification from specific type. The query passed in your link is not pretty. In my opinion you should create a proper queryBuilder - it's quite similar.
At the end you cannot use the $user->getNotifications(), but you have to get notifications directly from repository -
$em->get('AcmeBundle:User')->getForumPostNotifications()
Kind regards,
Piotr Pasich
This is in fact so simple, I'm amazed they've not documented it properly.
In your repository, do:
return $this->_em->createQueryBuilder()
->select('notification')
->from(Notification::class, 'notification')
// whatever else you need
please notice creating the query builder from entity manager, not entity repository itself
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.
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