Custom Item Data Provider

Hey Ahmedbhs,

Yeah, this is a good practice actually, we used this approach in our code as well. The exact variable name in the constructor args will requires Symfony to inject the specific service, that's how Symfony DI works behind the scene - it looks for the specific var name from bind :)

Another alternative solution would be to declare the service manually in services.yaml and specify passing the "@api_platform.doctrine.orm.default.item_data_provider" service manually.

Both should work, but usually devs using bind feature.

Cheers!

Hey @mwozniak!

Sorry for my slow reply - sometimes the deeper questions get left to me (and this is a good one!) and I was deep in tutorial land :). Now, let's see!

So this is not an area that I'm very familiar with. But here's what happens internally. Let's assume you hav this code:

$item = $this->itemDataProvider->getItem($resourceClass, $id, $operationName, $context);

When you call this, you almost immediately hit this code: https://github.com/api-platform/core/blob/d62e86e9cfa2a7a4eba3029053ff65f43a10e1ce/src/Bridge/Doctrine/Orm/ItemDataProvider.php#L75-L80

In most situations, where the $id you pass in is a string or int, the normalizeIdentifiers() method is called. You can find that here: https://github.com/api-platform/core/blob/d62e86e9cfa2a7a4eba3029053ff65f43a10e1ce/src/Bridge/Doctrine/Common/Util/IdentifierManagerTrait.php#L43

That method takes your string id and converts it into an array - for example ['id' => 4].

Then, back in getItem(), if $id is not an array at this point, you hit the exception you're seeing: https://github.com/api-platform/core/blob/d62e86e9cfa2a7a4eba3029053ff65f43a10e1ce/src/Bridge/Doctrine/Orm/ItemDataProvider.php#L78-L80

The question is... why is this happening? But first, let me answer this:

Where does has_identifier_converter comes from?

If you're using an id in your system that is... somehow custom (e.g. maybe you use an id that is the combination of a "slug" field, a dash, then the id $slug-$id), then you need to register a custom "identifier converter" that is capable of understanding this (i.e. splitting it into 2 pieces). This is not a context key that you would normally set yourself manually. It is a custom class you create, which API platform detects early in the request. It then sets this flag for you, so that it can handle your id conversion correctly.

So. my guess is that this is NOT what you're trying to do. In your case, something is going wrong with the "id" normalization, and the error you're getting isn't the best one. A better error for you would be:

Something went wrong trying to convert your id $id.

I know - still not that helpful - because we don't know what the problem here. So here is what I would do:

A) Add some debugging code right around here https://github.com/api-platform/core/blob/d62e86e9cfa2a7a4eba3029053ff65f43a10e1ce/src/Bridge/Doctrine/Orm/ItemDataProvider.php#L75-L77 - to make sure that you ARE getting inside that if statement.

B) Assuming you ARE getting into that if statement, add some debugging code to the normalizeIdentifiers() method to see why this isn't returning an array.

My guess is that you are in situation (A). That means that either:

1) You are passing an. $id that is not an int or string
2) Somehow, that has_identifier_converter IS being set to true by something.

Let me know what you find out!

Cheers!

Hi Szabolcs!

Sorry for my VERY slow reply - your question was left for me, and I've been lost in tutorial-creation land for a week or so :).

Ok, excellent question!

> If I write an custom DataProvider (maybe for User-Enities like in this example), than I will loose all the features like the QueryExtensions and OrmFilters. So this is the reason, why in this example the original DataProviders (Collection- and ItemProvider) was injected

Yes! Exactly! If we did NOT inject the original data providers (and instead, we simply queried for the object(s) ourself), we would be "avoiding" the query extension system, which also gives us things like pagination. So you are understanding this perfectly

> But in this example these decorated DataProviders returns the query-result, but I see no way here to make joins, which will be often the case!

Correct! The query has already been executed - so it's too late to change the query.

> If I want to make a join, should I write an QueryExtension, which is used in the decorated DataProvider

Yup! QueryExtension is your way to *modify* a query, which, in this example, will then be used by our decorated DataProvider. i know, it's complicated :). The QueryExtension and DataProvider have *slightly* different "superpowers". The QueryExtension can modify the query before it's executed, but it can't "modify" the entity objects that are returned, because the query hasn't actually be executed at that point. The DataProvider can't modify the query, but it can modify each entity object. That's why each serves a slightly different purpose.

Cheers!

Thank you for your answer! I have wrote an AbstractDataProvider which
allows access to the current query-builder. I believe, to be able to
make joins really belongs in a data-provider. QueryExtensions for me are
a place, where I put more "common things" like a "NotDeletedExtension"
and so on. Can I talk with Kevin Dunglas please? I just kidding :-p! I
really love your tutorial by the way, I'm watching it even when I'm on
vacation :-)! Best wishes!

Hey Ahmed,

if you're not going to work with the $context then it's not needed to implement that interface but it doesn't cause any harm if you do

Cheers!