Reusing Queries with the Query Builder

Hey Duilio P.

Ha! that's clever but I don't think you need to create your own "QueryBuilder" class and override the create method. You can add a method like this to your repository and it should just work as the same but cleaner

// yourRepository.php
use Doctrine\ORM\QueryBuilder;

  public function addSubSelect(QueryBuilder $queryBuilder, $alias)
  {
    $queryBuilder->addSelect(sprintf(
      '(%s) as %s',
      $queryBuilder->getDQL(), $alias
    ));
  }

public function yourCustomMethod()
{
     return $this->createQueryBuilder('s')
   ->select('s.country')
   ->addSubSelect($numberOfPayments, 'num_payments')
   ->addSubselect($totalAmount, 'amount')
   ->groupBy('s.country')
   ->getQuery()
   ->getResult();
}

Cheers!

Hello! Thanks for your reply. The code above didn't work in Doctrine 2.6. I only managed to make it work by adding more custom code haha. I've shared it below. I'd prefer to keep the custom query builder methods in the custom query builder most of the time, but this was an interesting proof of concept.

https://gist.github.com/sil...

Ohh, right! My code is wrong. You cannot chain the calls like that because the "addSubSelect" method exists only in the repository, silly me :)

> I'd prefer to keep the custom query builder methods in the custom query builder most of the time, but this was an interesting proof of concept.
Cool, thanks for sharing it

Cheers!

Hey Lubna,

It seems like you can't link the form type to a specific entity because information is stored in different databases... If so, then you can skip linking the form to a specific entity that will automatically link the form to an array, i.e. with $form->getData() you will get a simple PHP array. Then you will need to save the information from that array to different databases. Another common use case - create a "model" class for your form type with all the links you need and then link the form type to it. But that's in case you want to the form gives you an object where you can call getters later. The first option might be simpler for you I think. Just get the form data as plain PHP array and then do whatever you want with those data like set some of them on an entity, or execute some specific queries to any DB you need, or whatever :)

Cheers!

victor
Thank you very much! I did it :)

Hey Lubna,

Great! I'm happy to hear it worked for you :)

Cheers!

Hey!

I think that's fair - this could be said about any re-use: if you re-use less (e.g. keep code inside one function instead of creating another), then you can refactor that function later without side effects. If you abstract and call an outside function, then you indeed *do* need to be more careful when refactoring that private function. Of course, at least these are *private* - that drastically reduces the scope of places you need to look for side effects from changes :).

Cheers!

Hey Fabian Picone

Technically you are correct but sometimes you just want to do a couple of things in the same method, so I would say that that's ok to do it, but, you should refactor it as soon as you get one or two use cases that requires that action to be splitted.

Cheers!

When you want to do a couple of things in a method, the smell begins. So split the "things" out in single methods. A method should do only one thing. Its more testable.

I know this discussion is old but wanted to comment that I think the rule applies when the method does perform 2 different tasks, for example buildQueryAndSendEmail. In this case the method does only one thing (it adds more instructions to the query).

Hey Fabian,

Yes, I mostly agree with you, and in practice we do exactly this. But hey, this addFortuneCookieJoinAndSelect() method is so simple and has just one line of code ;)

Cheers!

Hey Fabian,

We're sorry about it, I moderated that comment. Not sure why this angers Timothy so much :/

Once again, I agree with you, and you have a good point. However, in practice, I think that's ok to use "and"/"or" when we're talking about 2 actions that do not exist without each other. Because in tests you need to test both of them and in a proper order too. Sometimes you can split into 2 private methods and call them from the public one, that makes sense if there's some complex logic and a lot of code for both actions.

Cheers!

Good call! It's one of those annoying times when there are TWO of a given class!