I'm currently following a Symfony tutorial, and I've gotten to the part of Doctrine bidirectional relations (sorry if the terms I'm using are wrong, I'm not an native English speaker). My model is based on an Advert (One-To-Many) that displays an array of Applications (Many-To-One) made to this Advert. So an Application has to be linked to an Advert, hence the nullable false :
class Application
{
/**
* #ORM\ManyToOne(targetEntity="App\Entity\Advert", inversedBy="applications")
* #ORM\JoinColumn(nullable=false)
*/
private $advert;
//
}
And I added an $applications attribute to my Advert class:
class Advert
{
/**
* #ORM\OneToMany(targetEntity="App\Entity\Application", mappedBy="advert")
*/
private $applications;
//
}
But when I use php bin/console make:entity --regenerate, to get the removeApplication() function, the code I'm getting is the following:
public function removeApplication(Application $application): self
{
if ($this->applications->contains($application)) {
$this->applications->removeElement($application);
// set the owning side to null (unless already changed)
if ($application->getAdvert() === $this) {
$application->setAdvert(null);
}
}
return $this;
}
The function sets the $advert of the Application to null while this attribute is explicitly set to nullable = false. I noticed this inconsistency because I'm using Symfony 4 whereas the tutorial I'm following is based on an older version, so the functions generated in the tutorial were much simpler and did not handle the $advert attribute.
Any idea why this is happening and if it might cause an error later in my project? Let me know if you need more pieces of code to understand the problem.
That really looks like a bug to me, they probably do not handle nullable cases inside of the generator.
Maybe try orphanRemoval on the Advert side of the relation, would be interesting what would happen then:
class Advert
{
/**
* #ORM\OneToMany(targetEntity="App\Entity\Application", mappedBy="advert", orphanRemoval=true)
*/
private $applications;
}
Related
Today, I've tried to upgrade my project to the new version of Symfony (3.3), and I'm encountering a problem with my mocks.
Until today, I was doing my mocks like this:
$client = $this->makeClient();
$mockObject = new \stdClass();
$mock = $this->getMockBuilder('SomeClass')
->disableOriginalConstructor()
->setMethods(['method1', 'method2'])
->getMock();
$mock->expects($this->once())
->method('method1')
->will($this->returnValue($mockObject));
$client->getContainer()->set('my_service', $mock);
Here, method1 is just a Guzzle post, nothing else.
Now, I'm getting the following error:
Setting the "my_service" pre-defined service is deprecated since Symfony 3.3 and won't be supported anymore in Symfony 4.0: 1x
After some research, it seems that I cannot use the last line of my code.
Problem is, I can't see nor find any solution to solve this deprecation.
There's few ways of solving your problem.
TestDoubleBundle
TestDoubleBundle makes it easier to create test doubles. You can use dependency injection tags to automatically replace a service with either a stub or a fake.
Override the container
Another way is to extend the container in the test environment, so it allows stubbing. Here's a draft of the idea:
<?php
namespace Zalas\Test\DependencyInjection;
use Symfony\Component\DependencyInjection\Container;
class MockerContainer extends Container
{
/**
* #var object[] $stubs
*/
private $stubs = array();
public function stub($serviceId, $stub)
{
if (!$this->has($serviceId)) {
throw new \InvalidArgumentException(sprintf('Cannot stub a non-existent service: "%s"', $serviceId));
}
$this->stubs[$serviceId] = $stub;
}
/**
* #param string $id
* #param integer $invalidBehavior
*
* #return object
*/
public function get($id, $invalidBehavior = self::EXCEPTION_ON_INVALID_REFERENCE)
{
if (array_key_exists($id, $this->stubs)) {
return $this->stubs[$id];
}
return parent::get($id, $invalidBehavior);
}
/**
* #param string $id
*
* #return boolean
*/
public function has($id)
{
if (array_key_exists($id, $this->stubs)) {
return true;
}
return parent::has($id);
}
}
To enable this container you'll need to override the getContainerBaseClass method in your AppKernel:
/**
* #return string
*/
protected function getContainerBaseClass()
{
if ('test' == $this->environment) {
return '\Zalas\Test\DependencyInjection\MockerContainer';
}
return parent::getContainerBaseClass();
}
You might need to tweak the code a bit, perhaps declare MockerContainer::$stubs as static (although if your previous approach worked it shouldn't be needed - it might be needed if you need to stub for multiple requests).
Now you should be able to use the container to stub services like this:
$client->getContainer()->stub('my_service', $myServiceStub);
Use a synthetic service
Another way of working around your issue is defining your service as synthetic. You could write a compiler pass that would only mark the service as synthetic in a test environment.
Your question is also discussed here.
You can take a look at this osservation:
Note that you don't need to fix the deprecations when moving to 3.3.
But you will when moving to 4.0.
And this workaround:
Well, you can mark these tests as #legacy to avoid making them fail
temporarily, to give you time to migrate the tests, if that takes
time. This is the whole point of deprecations: you can migrate
progressively (I also prefer removing deprecations as fast as
possible, but for some of them, it may require more time)
I'm using Symfony's Validator Getter Component In conjunction with symfony forms.
In one of my entities files, I have:
use Symfony\Component\Validator\Constraints as Assert;
class StudentPaper
{
.....
/**
* #Assert\IsTrue(message = "You must include a paper with your submission")
*/
public function hasPaper()
{
// I originally had logic that checked the validity, but just
// changed the return value to 'true' to prove that it's not working.
return true;
}
}
Unfortunately, the validation always fails (even when I hardcore the return value to be true). The validation code doesn't seem to be executed, and the form triggers the error. I even tried replacing it with IsFalse and hard coding false. Same result.
Anyone come across this?
Symfony 2.8.
PHP 5.6.15
Well, I can't fully explain what the actual problem is (because I don't know), but I did find a solution.
In my StudentPaper entity I had
/**
* Bidirectional - Student Papers have one file.
*
* #ORM\OneToOne(targetEntity="StudentPaperFile", inversedBy="student_paper", cascade={"persist", "remove"}, orphanRemoval=true)
* #ORM\JoinColumn()
* #Assert\Valid()
*/
protected $paper;
as a property. Turns out that having a property named paper AND a validation getter called hasPaper() was causing unexpected behavior. As soon as I changed the function name from hasPaper() to hasTesting() or hasSubmittedPaper then the getter worked as it was intended.
So the solution is that the getter function cannot be get/is/has + a mapped property name.
I have a Doctrine-Entity in my Symfony2-Project, which uses a custom Assert/Constraint to check, if a given date value is before and/or after a given date. This looks like the following simplified code:
In my entity class:
/**
* #var \DateTime
*
* #ORM\Column(name="entry_entered_at", type="date", nullable=true)
* #AppBundleAssert\DateRangeConstraint(max = "today")
*/
private $entryEnteredAt;
The relevant snippet of the corresponding DateRangeConstraint-class:
new \DateTime($this->max)
As you can see, I want to check, if a date is before today. The \DateTime-constructor is able to resolve this to a DateTime-object of today. Nice thing, works fine.
The problem
But it turns out, that Symfony2 caches all those Doctrine-annotations, so today is always resolved to the day, the cache was lastly cleared and my constraint produces nice form errors.
As a workaround for now, I clear the cache on a daily basis, but I need a better solution.
The question
So the question is, what would you suggest, how to implement such a dynamic assert/constraint in Symfony2?
I could implement the constraint inside the form, but it should be in the domain of the entity.
Edit:
I posted as answer and marked it as solution.
The solution and some answers
It turned out, that the built in Range validator is also able to validate a date-range. So I don't need my custom validator at all.
Digging a bit deeper into the built in Range constraint and the base Constraint class gives the reason, why the built in validators can use dynamic parameters like today, but not my incorrect implemented custom validator. The Constraint base class has a __sleep() method that just stores the object vars and its current values on serialization. Thus, when we don't reinitialize the object with a custom __wakeup() method, which would be a false workaround, we only get the cached parameters.
So besides the fact, that the builtin Range constraint already solves my problem, I simply should have done my dynamic new \DateTime($constraint->max) stuff inside the custom DateRangeConstraintValidator and not the cached custom DateRangeConstraint. Just have a look into Symfony\Component\Validator\Constraints\Range and Symfony\Component\Validator\Constraints\RangeValidator to see this in action.
Lessons learned
Your custom Constraint class will be serialized and cached and thus shouldn't do any dynamic things. Just validate the options and define the messages and stuff. Your dynamic validation things (and especially the initialization of dynamic parameters) must be done within your custom ConstraintValidator class.
I suggest you to look at Custom validator, especially Class Constraint Validator.
I won't copy paste the whole code, just the parts which you will have to change.
Extends the Constraint class.
src/Acme/DemoBundle/Validator/Constraints/CheckEntryEnteredAt.php
<?php
namespace Acme\DemoBundle\Validator\Constraints;
use Symfony\Component\Validator\Constraint;
/**
* #Annotation
*/
class CheckEntryEnteredAt extends Constraint
{
public $message = 'Your error message.';
public function validatedBy()
{
return 'CheckEntryEnteredAtValidator';
}
public function getTargets()
{
return self::CLASS_CONSTRAINT;
}
}
Define the validator by extending the ConstraintValidator class, entryEnteredAt is the field you want to check:
src/Acme/DemoBundle/Validator/Constraints/CheckEntryEnteredAtValidator.php
namespace Acme\DemoBundle\Validator\Constraints;
use Symfony\Component\Validator\Constraint;
use Symfony\Component\Validator\ConstraintValidator;
class CheckEntryEnteredAtValidator extends ConstraintValidator
{
public function validate($entity, Constraint $constraint)
{
$today = new \Datetime('today'); // = midnight
if ($entity->entryEnteredAt < $today) {
$this->context->addViolationAt('entryEnteredAt',
$constraint->message, array(), null);
}
}
}
Use the validator:
src/Acme/DemoBundle/Resources/config/validation.yml
Acme\DemoBundle\Entity\AcmeEntity:
constraints:
- Acme\DemoBundle\Validator\Constraints\CheckEntryEnteredAt: ~
(adapted from a previous answer)
public function __construct()
{
$this->entryEnteredAt = new \DateTime();
}
is something like that a solution for your use case? (on new YourEntity() you'll have a today date set for the entryEnteredAt property)
You could also use LifecycleCallbacks, here is an exemple with preUpdate (there is some more, like PrePersist):
on top of your class entity:
* #ORM\HasLifecycleCallbacks()
and
/**
* Set updatedAt
*
* #ORM\PreUpdate
*/
public function setUpdatedAt()
{
$this->updatedAt = new \DateTime();
}
Is there anything in the Symfony annotations modules that allow me to use them for other uses?
I know for #Route and #Method you need to extend existing libraries, so its just not that easy i'm guessing.
Currently, i'm working with the JS History API, and would LOVE to put the popState data for my JS files in the annotations. So they are already available when the routing generates the URL.
Q Doesn't this makes sense to have a, HTML5 annotated title, or some attribute here? It would be great to have the ability to define this data, as annotated, right next to the already existing route name and stuff.
Q Is there anybody that has tweaked with the annotations before?
I wanted to clarify my intentions here as I think I left out some crucial details (the mention of History API) for understanding my use case.
There is a few SPA front ends that have been integrated through a front-end bundle, and this connected via AJAX calls to a backend bundle which was a straight RESTful API, with the addition of a very fun-to-develop PHP API class I made that intereprets and processes (routes) the AJAX in a fashion that directly executes other PHP class controller `methods.
I use a lot of ajax for this Symfony 2 app (fosjsrouter) to handle routing. So instead of URLs triggering the routes and actions, the SPA click event fires off AJAX to the back end router, with a large JSON payload, not limited to PHP control parameter's (class/method/var names), and data sets.
OK, so getting back on track; Given the above scenario; In the JS class object end of the router, inside this I thought it was the best place to add some JS History API functionality to it, (state, back button, etc.)
The above class can be called if a history flag was called, which could become responsible for assigning initial state data. Primarily, this is because the JSON data object that's being around in this JS method contains already a lot of the crucial route data, and param information for that route needed in the backend PHP, which comes from the annotations.
So the idea is if I add accessibility for a history state title and URL to the annotations, then I will have access to that information right there available to define the initial state, if flagged, right inside the an ajax.done(), inside this main JS routing method.
Now we can pass state back and forth two ways between the db and realtime client-side async. You can use an observer, or anything, from there front-end, and jobs/queues on the backend to keep it fully reactive. (use React too :-))
EDIT I'm not so sure that's what I was thinking, it looks like its making me set the values of the title and url for this inside the return statement of the PHP function, where I want it set in the annotation (see return 'Matthias Noback';)
So I'm trying this, but where do I set these titles at?
<?php
namespace Blah\CoreBundle\Controller;
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
/**
* #Annotation
*/
class HistoryAnnotationController
{
//history state params are out properties here..
/**
* #var
*/
private $url;
/**
* #var
*/
private $title;
/**
*
*/
public function __construct()
{
}
/**
* #return mixed
*/
public function getTitle()
{
return $this->title;
}
/**
* #return mixed
*/
public function getUrl()
{
return $this->url;
}
}
I want to set it WAY back here, so the ajax that calls this route has access to it.. (look for #historyApiTitle in this code, etc..)
<?php
namespace Blah\Bundle\Controller;
use Symfony\Bundle\FrameworkBundle\Controller\Controller,
Symfony\Component\HttpFoundation\JsonResponse,
Sensio\Bundle\FrameworkExtraBundle\Configuration\Method,
Sensio\Bundle\FrameworkExtraBundle\Configuration\Route,
Sensio\Bundle\FrameworkExtraBundle\Configuration\Template,
Blah\Bundle\Entity\Test,
Doctrine\ORM\Query; //for hydration
class StuffController
{
/**
* #Route("/some/route/name/{test}", name="some_route_name", options={"expose"=true})
* #param $test
* #return mixed
* #historyApiTitle('This is the get something page')
* #historyApiUrl('/get_something')
*/
public function getSomethingAction($test)
{
$em = $this->getDoctrine()->getManager();
$dql = "
SELECT s
FROM BlahBundle:Stuff s
WHERE s.test = :test";
$query = $em->createQuery($dql);
$query->setParameter('test', $test);
$paginator = $this->get('knp_paginator');
$pagination = $paginator->paginate($query,
$this->get('request')->query->get('page', 1), 1000);
return $this->render('BlahBundle:Stuff:get_something.html.twig', array('pagination' => $pagination));
}
}
Q So looking at these TWO code examples, how do I connect the dots between the two to get this to work?
Yes you can annotations classes you can follow the following tutorial Creating Custom annotations Classes
Basic rules are the follows:
Your class should have the #Annotation -phpdoc comment
/**
* #Annotation
*/
class CustomAnnotation
{
public function __construct($options) {}
}
In Your Needed class just use it in standard way;
class Person
{
/**
* #CustomAnnotation("option")
*/
public function getName()
{
return 'some stuff';
}
}
You should looks at the AOPBundle, it allows you to do treatement from your personnals annotations. But I don't thinks trying to do annotations in the view is a good idea. You need to parse the javascript with php, and it sounds bad.
I don't know why, maybe i am missing some basic logic but I always run again into the same issue. I can't persists ManyToMany collections, and it also faces me with OneToMany collections, though I can work around that.
I read through the doctrine documentation, and I think I do understand the thing with mappedBy and inversedBy (where the last one is always the owner and therefor responsible for persisting the data, please correct me if I am wrong).
So here's a basic example that I have right now, which I can't figure out.
I have an Entity called Site:
#Site.php
...
/**
* #ORM\ManyToMany(targetEntity="Category", mappedBy="sites")
*/
protected $categories;
and another one called Category:
#Category.php
...
/**
* #ORM\ManyToMany(targetEntity="Site", inversedBy="categories")
* #ORM\JoinTable(name="sites_categories")
*/
protected $sites;
Using the Symfony2 entity genenerator it added me some getters and setters to my Entites which look like this.
Site:
#Site.php
...
/**
* Add categories
*
* #param My\MyBundle\Entity\Category $categories
*/
public function addCategory(\My\MyBundle\Entity\Category $categories)
{
$this->categories[] = $categories;
}
/**
* Get categories
*
* #return Doctrine\Common\Collections\Collection
*/
public function getCategories()
{
return $this->categories;
}
The same counts for
Category:
#Category.php
...
/**
* Add sites
*
* #param My\MyBundle\Entity\Site $sites
*/
public function addSite(\My\MyBundle\Entity\Site $sites)
{
$this->sites[] = $sites;
}
/**
* Get sites
*
* #return Doctrine\Common\Collections\Collection
*/
public function getSites()
{
return $this->sites;
}
Fair enough.
Now in my controller, I am trying to persist a Site object:
public function newsiteAction() {
$site = new Site();
$form = $this->createFormBuilder($site); // generated with the FormBuilder, so the form includes Category Entity
// ... some more logic, like if(POST), bindRequest() etc.
if ($form->isValid()) {
$em = $this->getDoctrine()
->getEntityManager();
$em->persist($site);
$em->flush();
}
}
The result is always the same. It persists the Site Object, but not the Category entity. And I also know why (I think): Because the Category entity is the owning side.
But, do I always have to do something like this for persisting it? (which is actually my workaround for some OneToMany collections)
$categories = $form->get('categories')->getData();
foreach($categories as $category) {
// persist etc.
}
But I am running into many issues here, like I would have to do the same loop as above for deleting, editing etc.
Any hints? I will really give a cyber hug to the person who can clear my mind about that. Thanks!
.
.
.
UPDATE
I ended up changing around the relationship (owning and inverse side) between the ManyToMany mapping.
If somebody else runs into that problem, you need to be clear about the concept of bidrectional relationships, which took me a while to understand too (and I hope I got it now, see this link).
Basically what anserwed my question is: The object you want to persist must always be the owning site (The owning site is always the entity that has "inversed by" in the annotiation).
Also there is a concept of cascade annotation (see this link, thanks to moonwave99)
So thanks, and I hope that helps somebody for future reference! :)
Regarding OneToMany relationship, you want to know about cascade annotation - from Doctrine docs [8.6]:
The following cascade options exist:
persist : Cascades persist operations to the associated entities.
remove : Cascades remove operations to the associated entities.
merge : Cascades merge operations to the associated entities.
detach : Cascades detach operations to the associated entities.
all : Cascades persist, remove, merge and detach operations to associated entities.
following docs example:
<?php
class User
{
//...
/**
* Bidirectional - One-To-Many (INVERSE SIDE)
*
* #OneToMany(targetEntity="Comment", mappedBy="author", cascade={"persist", "remove"})
*/
private $commentsAuthored;
//...
}
When you add comments to the author, they get persisted as you save them - when you delete the author, comments say farewell too.
I had same issues when setting up a REST service lately, and cascade annotation got me rid of all the workarounds you mentioned before [which I used at the very beginning] - hope this was helpful.