Filtrar y buscar

Hey Dima

I think I just spotted your problem. You're using "Boolean::class" instead of "BooleanFilter::class". Change that, and give it a try :)

Cheers!

Aah, yeah, indeed! My bad! Thank you

Hey Raul M.!

Hmm. I have no idea! I've never used it, but it looks like you can configure your filters inside ApiResource if you know the service id of each filter - 2nd code block - https://api-platform.com/do...

And so... you MIGHT be able to add a "filters=" option under the collectionOperation's config (instead of inside ApiResource). But, I'm doing some guessing. And for this to work, I think you need to look up the service id of the filter you want.

So... maybe? But it's definitely not a common use-case.

Cheers!

Hey Anton B.!

Sorry for my slow reply! This is a tricky question. Hmmm. Would it be possible to implement this entirely as a query extension? Here's the idea: in the query extension, you read the query parameter directly from the request. If it's present, you perform the joins necessary and modify the query to only return the en language. You could (and probably should) still have a Filter, because that's what causes the filter to show up in your documentation... you just wouldn't actually do the filtering logic in the filter class.

Buuuut, I have a feeling that I'm not thinking about some complication. Because you mentioned:

it can be only achieved by return $queryBuilder->getQuery()->getResult(); right from the Custom Filter

I don't understand why that's the case. Why can't you modify the query in the custom filter and allow the system to actually execute like normal? You would modify the query to have the joins and the WHERE for the language. Am I missing a complication?

Cheers!

weaverryan , thank you for the reply, I thought a lot about this, and my conclusion is that my case is not a proper way of using the API Platform and REST itself. I think we shouldn't modify the child collection results. But if we still need to modify(filter) the child collection, the best way is to perform the separate request to that collection with another filter.

Hey Mark V.!

This looks perfectly fine to me - I would do it the exact same way. You are hitting the collection endpoint, then filtering the results - I don't see any problems with that :).

> The only downside I can see is hitting the query string length limit when retrieving many items

That's true... but there is really no other way to send data up on a GET request - this IS the proper way. Hopefully, if you hit the situation, there would be some other way to filter... or... I'm not sure - I'm having a hard time imagining how you could send any GET request up there with SO much data (maybe as header?). Hopefully you don't have this problem ;).

Cheers!

Hey Daniel K.

I believe you can't but give it a try. What are you trying to achieve? Perhaps you need a custom filter instead

Cheers!

Hey truuslee

Thanks for your kind words. Related to your question, I'm not totally sure because we don't talk about integrating ES with ApiPlatform but I found this in the docs:
https://api-platform.com/do...

It says that you should create a custom extension, so here is the link to it: https://api-platform.com/do...

I hope it helps. Cheers!

Hey Michel B.

I'm afraid there is not a built-in filter for such task. I believe you have to create a custom filter, you can read how to do so here https://api-platform.com/do...

I hope it helps. Cheers!

Hey Martin

My first guess is that you may not have a getter for the status property. Another thing to check is the imports, double-check that you imported the right ones

Cheers!

Hey MolloKhan!

Thanks for replying!

I have created the entity using <a href="https://packagist.org/packages/symfony/maker-bundle&quot;&gt;maker bundle</a>, so the property getter is there. Also, this is what my Question imports looks like:

`
use ApiPlatform\Core\Annotation\ApiResource;
use App\Repository\QuestionRepository;
use Doctrine\Common\Collections\ArrayCollection;
use Doctrine\Common\Collections\Collection;
use Doctrine\ORM\Mapping as ORM;
use ApiPlatform\Core\Bridge\Doctrine\Orm\Filter\SearchFilter; // here
use ApiPlatform\Core\Annotation\ApiFilter; // and here
use Symfony\Component\Serializer\Annotation\Groups;

/**

• @ORM\Entity(repositoryClass=QuestionRepository::class)
• @ApiResource(normalizationContext={"groups"={"question"}})
• @ApiFilter(SearchFilter::class, properties={"status": "partial"})
  */
  class Question
  {
  //....
  }
  `

I have followed <a href="https://api-platform.com/docs/core/filters/&quot;&gt;this guide</a> too.

Hmm, that's very strange. The setup looks right. What happens when you play with the API? Can you do a GET and POST request successfully?
What version of Symfony and ApiPlatform are you using?
If you create a new entity does it behaves the same?

Diego, I have tried to replicate the issue on a new project and it worked. So, I assume the problem was some alternate configuration on the project. I was able to play with the API, posting and getting entities. Not sure. But I will try to copy the project with a new configuration. Thank you anyway!

Ohh, that's interesting. Perhaps if you upgrade ApiPlatform the error goes away but I might be wrong. Cheers!

Hey Benjamin K.!

> If i am right select - where is allready done. A custom Filter is AndWhere from queryBuilder. That makes sense we filter a resource and not build a complete query

That's correct :). It makes the filters fairly easy to build.

Cheers!

Hey Martin!

Hmm, good question! A normal SearchFilter would, in theory, work (as you would be searching through the JSON string)... but it would be fairly imprecise. To do this correctly, you would probably need to create a API Platform custom filter. Then, assuming you're using a database with a proper JSON type (like pgsql or MySQL 5.7 or higher), you would need to do a bit more work to query for the item via Doctrine. Basically, because JSON types are not supported across all database systems, as far as I know, there is no built-in way to properly query a JSON type in Doctrine. But there are resources out there - e.g. https://blog.liplex.de/sear... - about how to do this.

Let me know if that helps!

Cheers!

Hey weaverryan.

Thanks for replying. It really helped. Thank you. I am not sure why but is not documented in Swagger UI. I guess this is because of the value returned (return $this->json($users);. But it's working!

Hi Manuka L.!

Sorry for the slow reply! I believe you will need to create a custom filter for this. The built-in filters always use AND logic... I think it's, sort of, just a missing feature when you configure the search filter (in my opinion). Here is an issue about this - https://github.com/api-plat... - and a gist that will hopefully help: https://gist.github.com/axe...

Cheers!

hi ahmedbhs!

Hmm. Maybe? :) I'm not sure I fully understand. Your Swagger docs (or more technically accurate, the OpenAPI specification) are "static" - you can view them by going to /api/docs.json. So, this is not something that can be affected by query parameters to a specific endpoint - it's a 100% static definition of your API.

So, what are you trying to accomplish exactly? Do you want to make it possible to POST a field... but ONLY when the URL has newQuery=true? If so, that might be done with a context builder - https://symfonycasts.com/screencast/api-platform-security/context-builder - if the query param exists, then add a new group that the field is in. Or do you want something different?

Cheers!

Hey Olivier

That's a good question and by looking at the ApiPlatform docs I couldn't find anything related to define 2 strategies on the same property. So, I think what you need to do is to create your own filter by following this steps: https://api-platform.com/do...

Cheers!

Hey truuslee!

Sorry for my slow reply. Honestly, I'm not sure if there is a strictly-agreed-upon best practice for this or not. You've listed 2 possible options - and there is (technically) one more - having the language in the URL - e.g. /api/en/articles, though this last one doesn't feel very RESTful to me (as it would mean that, in a philosophical level, /api/en/articles/1 and /api/es/articles/1 are different rest "resources").

So, I would choose between the two options that you listed - choosing which ever one would be most convenient for whoever is using your API. Maybe the "accept language" header is a better practice, but I wouldn't stress out over it if the query parameter is more convenient. Let's look at the implementation details of each:

A) If you used, ?language=en, then probably it would mean that your API is designed so that if, for example, I make a request to /api/articles that it returns the list of ALL articles in ALL languages. Then adding the language filter is just a matter of using the built-in API Platform filters.

B) If you used the "accept language" header, you have a little bit more work to do. You would need to parse the "accept language" header to determine which language to ultimately use. I would then probably create an "API Platform Doctrine extension" - https://api-platform.com/docs/core/extensions/ - that would limit the collection or choose the item result based which language you determine is correct. Then you should also add a Content-Language response header set to which language you ultimately chose. I would do that via a listener - https://api-platform.com/docs/core/events/#custom-event-listeners - the POST_RESPOND one (which just means you add a listener to the kernel.response event - called ResponseEvent in Symfony 4.3 and higher.

Let me know if this helps! Mostly, follow what will be most useful in your API - it sounds like you are only considering solid option.

Cheers!

Thank you very much for your reply. You're a big help as always. I've chosen to do it with a filter, far less work.
I have other questions for you, I hope you don't mind?

1.
I have an entity Brand that is related to another entity called Product. (One product has one Brand, one Brand has many Products).
Now the api-client wants a list of all the brands a customer is using.
Something like this:
/api/customer/{id}/brands

But entity Brand is not related to the Customer entity, I can only get the brands via entity1 related to entity2, related to entity Product, finally related to entity Brand.
How can i do this?
I am thinking about creating a new entity with customer ids and brand ids together in a 'cross' table. But i hope there is a better way?

1. I have created a Custom Doctrine ORM Extension.
   Because I want to add a groupby to a query.
   This works great, it makes sure the result set is grouped.
   But one thing is wrong. The hydra variable "<b>hydra:totalItems</b>" is still mentioning the original amount of records, as if there were no groupby.
   This is my code:
   `

final class FooExtension implements QueryCollectionExtensionInterface, QueryItemExtensionInterface
{

public function applyToCollection(QueryBuilder $queryBuilder, QueryNameGeneratorInterface $queryNameGenerator,
    string $resourceClass, string $operationName = null): void {
    $this->addGroupBy($queryBuilder, $resourceClass);
}

public function applyToItem(QueryBuilder $queryBuilder, QueryNameGeneratorInterface $queryNameGenerator,
    string $resourceClass, array $identifiers,string $operationName = null,array $context = []): void {
    $this->addGroupBy($queryBuilder, $resourceClass);
}

private function addGroupBy(QueryBuilder $queryBuilder, string $resourceClass): void
{
    if (Foo::class !== $resourceClass) {
        return;
    }
    $rootAlias = $queryBuilder->getRootAliases()[0];
   <b> $queryBuilder->addGroupBy($rootAlias . '.foo_field');</b>
}

}
`

How can i make hydra show me the correct number of records?

Thanks in advance and hope to hear from you soon!

Hey truuslee!

But entity Brand is not related to the Customer entity, I can only get the brands via entity1 related to entity2, related to entity Product, finally related to entity Brand.
How can i do this?
I am thinking about creating a new entity with customer ids and brand ids together in a 'cross' table. But i hope there is a better way?

Hmm. Ideally we can avoid adding duplication to our database to make API Platform happy :). My initial instinct (which is a bit of cheating) is to tell the API client to use a different endpoint. What I mean is: why do they need this specific endpoint? It's definitely possible to add it - but there could be a much simpler solution if we have some flexibility. For example, a URL like /api/brands?customer=/api/customers/1 would probably be easier, though this would still need to be a custom filter (since there is not actually a "customer" property on brands). Another option would be to simply "add" a brands field when you fetch a customer (instead of making it a different URL). You could probably do this by adding a getBrands() method to Customer that loops over all the products and then returns an array of each Brand that is related to all the Products (if I've understood the relationships correctly).

But anyways, to implement this, I would create a custom item operation on Customer for the /api/customers/{id}/brands URL. I try to avoid having custom operations because it usually means you're trying to "bend" the system a little far - but it's not a huge deal, and you need to get your job done :). In this case, you would write a custom controller and be able to do whatever you want.

But one thing is wrong. The hydra variable "hydra:totalItems" is still mentioning the original amount of records, as if there were no groupby.

Interesting! I don't know the answer to this - bit I'm a little surprised by it. The reason is that, behind the scenes, API Platform uses a "Doctrine paginator"... and since we're using Doctrine to build the query, I would expect it to be smart enough to get the proper count. Here is the code behind this: https://github.com/api-platform/core/blob/master/src/Hydra/Serializer/CollectionNormalizer.php#L96-L102

For you (and me), $object is an instance of ApiPlatform\Core\Bridge\Doctrine\Orm which is just a wrapper around Doctrine\ORM\Tools\Pagination\Paginator.

I'd be interested what the count query looks like. Typically (assuming you have a result that requires "pagination" - like more than 25 records) Doctrine will make a query specifically to get the total count (in addition to the query to get the specific results it needs). After making the API request, you can go to /_profiler to find the profiler for that API request. If you click into this and go to the Doctrine tab on the left, you'll be able to see all the queries including a query where Doctrine is trying to take your query and use it to get a count of all items. I'd be interested to know if that query looks "wrong" in some way.

I hope this helps!

Cheers!

Hi Gustavo!

Good question - I actually don't know! Here are how I think it might look (stolen from a few Stack Overflow references):

App\Entity\CheeseListing:
    attributes:
        filters:
            - 'ApiPlatform\Core\Bridge\Doctrine\Orm\Filter\BooleanFilter'
            # I'm not sure how you would pass a filter with options. Maybe this?
            ApiPlatform\Core\Bridge\Doctrine\Orm\Filter\SearchFilter:
                properties: [{title: partial}]

Let me know if it works :).

Cheers!

Hey Sung L.!

Sorry for my slow reply - great question. There are two probable approaches to this:

1) Use the elastic search integration: https://api-platform.com/do... - it's very robust, but could be overkill if you just need to do something simple.

2) Create a custom class (not a Doctrine entity, but you can still put it in the Entity directory) that contains whatever fields you want... which is maybe just a "results" array that will contain a mixture of objects? You will only want the "read" operations to be enabled for this resource (and probably just the collection operation). Then, use a custom data provider (https://api-platform.com/do... to take control of how you fetch the "collection". I'm not exactly sure how this would all look in the end, however... as I'm just "thinking" out loud. Assuming you created some custom class called ListingSearchResult and marked this an ApiResource, I guess you might give that properties like "item", which will be a CheeseListing or WineListing embedded object... and... I'm not sure if you need any other properties. So, the endpoint may look a bit funny.

I don't have a super great answer for this - well for suggestion (2). I think it could work and be nice... but it would need some more investigation. And, we might need to take some inspiration from what the ElasticSearch implementation looks like in Api Platform. Of course, you could always create a traditional endpoint that returns the results... e.g. just query for the array of CheeseListing & WineListing objects, then serialize that collection to the "jsonld" format.

Sorry I couldn't be more clear - this is not totally clear in my head, obviously :).

Cheers!

Ok, nice suggestions. I mean, thats something very common. A customer want to have a nice applications search and want me to write a search for some entities at once. I searched for a while for ElasticSearch implementation. And that reading and filtering process sounds very clear and easy but for writing and persisting thats another issue - I guess. Are there ressources how to get the ElasticSearch entites into the Database with Api-Platform?

Hey Hamid,

We're trying to release one video per day! Most probably this course should be completely released in the beginning of the next week. Thank you for your patience!

Cheers!

Thanks for you fast reply.