Let's imagine these 2 entities:
ShoppingCart
creationDate
Item
name
shoppingCart # ManyToOne
I'm managing a ShoppingCart in a form with a CollectionType of Items
public function buildForm(FormBuilderInterface $builder, array $options)
{
// ...
$builder
// ...
->add('items', CollectionType::class, array(
'entry_type' => ItemFormType::class,
// ...
}
I'd like my users to be able to add/remove items, which seems to me like a quite common need.
If I understand well, here is what I have to do:
Define the reverse OneToMany side of the ShoppingCart relation to Item
Make sure this relation have the cascade={"persist"} and orphanRemoval=true options
Initialize this items Collection into the constructor
Set the allow_add and allow_delete form option to true
Set the by_reference form option to false
Make sure andItem() & removeItem() functions are implemented into ShoppingCart
Set/unset the owning side relation to the ShoppingCart in addition to add/remove the Item from the ShoppingCart items collection
Keep the collection indexes within javascript so Doctrine can keep track of references
Am I forgetting something ?
I find it a big pain in the arse for me compared to the need and to other frameworks/ORMs
Is there a way to do it simpler ?
As I understand, your question is "why is it so complicated", isn't it?
Well, it's not. You've listed things multiple layers in your project. To exaggerate the point a little bit - why didn't you wrote that in order to create this form you need to install Symfony or even turn on your computer. ;-)
Anyway, most of these things are not required, others should be done before anyway.
Let's start with your OneToMany relation (Doctrine level).
ShoppingCart is your aggregate root (DDD term, but it doesn't matter if you follow DDD idea), which means you probably will do most of work on this object which will handle Items inside. If so, then you should have done inversed side of the relation, which covers these points (I think you went into details so much to make your list longer ;-), they all should be in one list item), but it takes a minute to do this stuff:
Define the reverse OneToMany side of the ShoppingCart relation to Item
Make sure this relation have the cascade={"persist"} and orphanRemoval=true options
Initialize this items Collection into the constructor
Make sure andItem() & removeItem() functions are implemented into ShoppingCart
Set/unset the owning side relation to the ShoppingCart in addition to add/remove the Item from the ShoppingCart items collection
This has nothing to do with forms. It's about how you want your entities to work with Doctrine.
Following two are not required:
Set the allow_add and allow_delete form option to true
Set the by_reference form option to false
They are about enabling/disabling features. You want them, so you need to use them. That's obvious and still not so much to do.
Last one:
Keep the collection indexes within javascript so Doctrine can keep track of references
This is the one that I actually don't understand. But what you need (in your case, because you're using allow_add/delete feature), is to provide JavaScript code that will create HTML for new row or delete existing one. But that's also just about copying prototype code. Also there are ready examples in Symfony's doc.
Let me answer myself in a simpler manner:
No I am not forgetting anything
No we can't do simpler
Some reasons are explained in #dragoste answer
Typically when you implement a entity using Doctrine you map it to a table explicitly:
<?php
/**
* #Entity
* #Table(name="message")
*/
class Message
{
//...
}
Or you reply on doctrine to implicitly map your class name to a table...I have several tables which are identical in schema but I do not wish to re-create the class for each time...there fore at runtime (dynamically) I would like to change the table name accordingly.
Where do I start or what would I look into overriding to implement this odd requirement???
Surprisingly (to me), the solution is very simple. All you have to do is to get the ClassMetadata of your entity and change the name of the table it maps to:
/** #var EntityManager $em */
$class = $em->getClassMetadata('Message');
$class->setPrimaryTable(['name' => 'message_23']);
You need to be careful and do not change the table name after you have loaded some entities of type Message and changed them. It's a big chance it will either produce SQL errors on saving (because of table constraints, for example), if you are lucky or it will modify the wrong row (from the new table).
I suggest the following workflow:
set the desired table name;
load some entities;
modify them at will;
save them;
detach them from the entity manager (the method EntityManager::clear() is a quick way to start over);
go back to step 1 (i.e. repeat using another table).
The step #5 (detach the entities from the entity manager) is useful even if you don't change or don't save the entities. It allows the entity manager use less memory and work faster.
This is just one of the many methods you can use to dynamically set/change the mapping. Take a look at the documentation of class ClassMetadata for the rest of them. You can find more inspiration in the documentation page of the PHP mapping.
I would like to set up transitive persistence in the single table inheritance mapping I’ve developed with doctrine in zf2. I’ve set up the mapping similar to the example presented in doctrine’s documentation for single table inheritance:
/**
* #Entity
* #InheritanceType("SINGLE_TABLE")
* #DiscriminatorColumn(name="discr", type="string")
* #DiscriminatorMap({"person" = "Person", "employee" = "Employee"})
*/
class Person
{
// ...
}
/**
* #Entity
*/
class Employee extends Person
{
// ...
}
If a record from the Employee table ever gets damaged or goes missing, I'd like for it to get replaced. However, the example above does not provide for that functionality on its own and doctrine won't allow me to write an INSERT dql in an error checker because they say entities and their relations have to be introduced into the persistence context through EntityManager#persist() to ensure consistency of your object model.
Examples in doctrine’s documentation for cascade operations show a neat way to place cascade settings in a #OneToMany mapping statement. However, none of the class table inheritance mapping statements (#InheritanceType, #DiscriminatorColumn, or #DiscriminatorMap) seem to want to accept cascade settings this way.
How and where can the cascade operations be configured for a single table inheritance strategy?
Using Doctrine 2 with Zend Framework 2. Been thinking of how I am meant to persist an entity with a field having a Many-To-One association with another entity that already exists in the database. Would I have to fetch the inverse side from the database first and then adding it to the owning Entity before persisting to the database as in the code below.
//$data = $_POST;
$book = new Book();
$author = $em->getRepository('Application\Entity\Book')->find($data['author_id']);
$book->setTitle($data['title'])
->setISBN($data['title'])
->setAbstract($data['abstract'])
->setYear($data['year'])
->setAuthor($author);
$em->persist($book);
$em->flush();
Normally, without using doctrine, all I have to do is update the author_id field of the Book entity above and persist to the Database. But now I have to make a trip to the Database to fetch the author details to create the entity and thus the association and then persist.
Is this the way it should be done or there is another way that doesnt involve fetching the author's details.
As you can read here
The method EntityManager#getReference($entityName, $identifier) lets
you obtain a reference to an entity for which the identifier is known,
without loading that entity from the database. This is useful, for
example, as a performance enhancement, when you want to establish an
association to an entity for which you have the identifier.
You could simply do this:
$book = new Book();
$book->setAuthor( $em->getReference('Application\Entity\Author',$data['author_id']));
I have a query that looks like this:
My user entity has a one-to-one relation that looks like this:
/**
* #var UserProfile
*
* #ORM\OneToOne(targetEntity="UserProfile",mappedBy="user")
*/
private $userProfile;
Anytime I make a query to select multiple user objects, it creates an additional select statement per user to query for the UserProfile data even though I am not accessing it through a get method. I don't always need the UserProfile data, and I certainly don't want to load this data every single time I'm displaying a list of users.
Any idea why these queries are executed at run time?
Here is solutions explain with details :
https://groups.google.com/forum/#!topic/doctrine-user/fkIaKxifDqc
"fetch" in the mapping is a hint, that is, if it is possible
Doctrine does that, but if its not possible, obviously it does not.
Proxying for lazy-loading is simply not always possible, technically.
The situations where its not possible are:
1) one-to-one from inverse to owning side (appears only in
bidirectional one-to-one associations). Precondition a) above can not
be met. 2) one-to-one/many-to-one association to a hierarchy and the
targeted class has subclasses (is not a leaf in the class hierarchy).
Precondition b) above can not be met.
In these cases, proxying is technically not possible.
Your options to avoid this n+1 problem:
1) fetch-join via DQL: "select c,ca from Customer join c.cart ca".
Single query but join, however, joins on to-one associations are
relatively cheap.
2) force partial objects. No additional queries but
also no lazy-load: $query->setHint(Query::HINT_FORCE_PARTIAL_LOAD,
true)
3) if an alternative result format (i.e. getArrayResult()) is
sufficient for a use-case, these also avoid this problem.
Benjamin had some ideas about automatic batching of these loads to
avoid n+1 queries but this does not change the fact that proxying is
not always possible.
I spent a lot of time searching for a solution. For me, none of the options were satisfying enough, but maybe I can save someone some time with this list of workarounds:
1) Change the owning side and inverse side http://developer.happyr.com/choose-owning-side-in-onetoone-relation - I don't think that's right from a DB design perspective every time.
2) In functions like find, findAll, etc, the inverse side in OneToOne is joined automatically (it's always like fetch EAGER). But in DQL, it's not working like fetch EAGER and that costs the additional queries. Possible solution is every time to join with the inverse entity
3) If an alternative result format (i.e. getArrayResult()) is sufficient for some use-cases, that could also avoid this problem.
4) Change inverse side to be OneToMany - just looks wrong, maybe could be a temporary workaround.
5) Force partial objects. No additional queries but also no lazy-loading: $query->setHint (Query::HINT_FORCE_PARTIAL_LOAD, true) - seams to me the only possible solution, but not without a price:
Partial Objects are a little bit risky, because your entity behavior is not normal. For example if you not specify in ->select() all associations that you will user you can have an error because your object will not be full, all not specifically selected associations will be null
6) Not mapping the inverse bi-directional OneToOne association and either use an explicit service or a more active record approach - https://github.com/doctrine/doctrine2/pull/970#issuecomment-38383961 - And it looks like Doctrine closed the issue
It seems that this is a open issue in Doctrine, see also
4.7.1. Why is an extra SQL query executed every time I fetch an entity with a one-to-one relation?
If Doctrine detects that you are fetching an inverse side one-to-one association it has to execute an additional query to load this object, because it cannot know if there is no such object (setting null) or if it should set a proxy and which id this proxy has.
To solve this problem currently a query has to be executed to find out this information.
Source
As #apfelbox explained... there is no fix for it now.
I went for a OneToMany solution in a combination with unique key:
User.php
/**
* #ORM\OneToMany(targetEntity="TB\UserBundle\Entity\Settings", fetch="EXTRA_LAZY", mappedBy="user", cascade={"all"})
*/
protected $settings;
/**
* #return \Doctrine\Common\Collections\Collection
*/
public function getSettings()
{
return $this->settings;
}
And
Settings.php
/**
* #ORM\ManyToOne(targetEntity="TB\UserBundle\Entity\User", fetch="EXTRA_LAZY", inversedBy="settings")
* #ORM\JoinColumn(name="user_id", referencedColumnName="id", nullable=false)
*/
protected $user;
And to ensure the uniqueness in Settings.php include:
use Doctrine\ORM\Mapping\UniqueConstraint;
And add unique index
/**
* #ORM\Entity
* #ORM\Table(name="user_settings", uniqueConstraints={#UniqueConstraint(name="user", columns={"user_id"})})
*/
class Settings
So when I want to access the user Settings I just need to this (which will fire ONE query ONLY in that specific moment)
$_settings = $user->getSettings()->current();
I think is the cleanest solution.
There is another option (which is the best IMHO) - you could use unidirectional OneToOne.
In your case - if you use UserProfile rarely - setup link in UserProfile
/**
* #var User
*
* #ORM\OneToOne(targetEntity="User")
*/
private $user;
And just dont map it in User. You could load it, when you will need it.
If you use UserProfile often - you could make it part of User entity.
According to the reference you can add the optional attribute fetch
/**
* #var UserProfile
*
* #ORM\OneToOne(targetEntity="UserProfile",mappedBy="user", fetch="LAZY")
*/
private $userProfile;