Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Add polymorphism support (based on discriminator)

Aperta
  • Qualcosa non va?
#6,915 2 commenti 1 reazione 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
openapi, php, symfony
Ambito
api, backend, backend-api-design

Direzione di ricerca

Inizia leggendo PropertyNameCollectionFactory e PropertyMetadataFactory, quindi segui i percorsi del normalizer di Serializer e del generatore di schemi descritti nell’issue. Il lavoro è completato quando le sottoclassi basate su discriminator serializzano e deserializzano le proprie proprietà e viene considerato il supporto richiesto per il polimorfismo OpenAPI.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Description
This was already closed in https://github.com/api-platform/core/issues/2931, but I would like you to reconsider.

Since it's quite limiting not being able to use Doctrine's Inheritance mapping and OpenAPI has nowadays quite good polymorphism support thanks to discriminator, oneOf, anyOf etc, I believe it makes sense to reconsider support of this. At beginning, I think most people would be fine if APIP at least allowed serialization/deserialization of properties in subclasses. Schema generator could be adjusted later to generate things like this
image

Main issue I would like to solve is that serializer does not see properties from subclasses. After further debugging I found that PropertyNameCollectionFactory and PropertyMetadataFactory are responsible. However, these factories only accept $resourceClassand not an actual class that Serializer is serializing/deserializing, hence it's not possible to simply add own implementation of these factories.

Example

#[ApiResource()]
#[Doctrine\ORM\Mapping\Entity()]
#[Doctrine\ORM\Mapping\InheritanceType('SINGLE_TABLE')]
#[Doctrine\ORM\Mapping\DiscriminatorColumn('type', 'string')]
#[Doctrine\ORM\Mapping\DiscriminatorMap(self::DISCRIMINATOR_MAPPING)]
#[Symfony\Component\Serializer\Attribute\DiscriminatorMap('type', self::DISCRIMINATOR_MAPPING)]
abstract class DatasyncConnector {
    private const array DISCRIMINATOR_MAPPING = ["SCIM" => SCIMConnector::class, "JSON" => JSONConnector::class];

    public string $type;
}
{}

#[ORM\Entity()]
class SCIMConnector extends DatasyncConnector {
  public ?string $foo = null;
}

#[ORM\Entity()]
class JSONConnector extends DatasyncConnector {
  public ?string $bar = null;
}

Here, I expect serialization will result in

{"type": "SCIM", "foo": "string"}

or

{"type": "JSON", "bar": "string"}

Similarly, deserialization should accept (and write to) these properties

Further context
Currently, I have added support for this in application I'm maintaining by enabling allow_extra_attributes and implementing custom normalizer:

#[AutoconfigureTag('serializer.normalizer', ['priority' => 1])]
class DatasyncConnectorNormalizer implements NormalizerInterface, DenormalizerInterface
{
    public function __construct(
        #[Autowire(service: 'serializer.normalizer.object')]
        private ObjectNormalizer $normalizer,
        #[Autowire(service: 'api_platform.jsonld.normalizer.item')]
        private AbstractNormalizer $jsonldNormalizer,
    ) {}

    public function denormalize(mixed $data, string $type, ?string $format = null, array $context = []): mixed
    {
        return $this->normalizer->denormalize(
            $data,
            $type,
            $format,
            [
                AbstractNormalizer::OBJECT_TO_POPULATE => $this->jsonldNormalizer
                    ->denormalize($data, $type, $format, $context),
            ] + $context,
        );
    }

    public function supportsDenormalization(
        mixed $data,
        string $type,
        ?string $format = null,
        array $context = [],
    ): bool {
        return true;
    }

    public function normalize(
        mixed $data,
        ?string $format = null,
        array $context = [],
    ): null|array|\ArrayObject|bool|float|int|string {
        \assert($data instanceof DatasyncConnector);

        $context['uri_variables'] = ['id' => $data->id];

        return $this->jsonldNormalizer->normalize($data, $format, $context)
            + $this->normalizer->normalize($data, $format, $context);
    }

    public function supportsNormalization(mixed $data, ?string $format = null, array $context = []): bool
    {
        return true;
    }

    public function getSupportedTypes(?string $format): array
    {
        return [DatasyncConnector::class => true];
    }
}

Even OpenAPI schema is adjusted thanks to implementing own OpenApiFactory which generates definitions for subclasses, then linking to them from resource like so

new GetCollection(openapi: new OpenApiOperation(responses: [
    200 => new Response(content: new \ArrayObject(['application/ld+json' => [
        'schema' => [
            'type' => 'array',
            'items' => [
                'oneOf' => [
                    ['$ref' => self::SCHEMA_PATH_PREFIX.'.jsonld-connector.output'],
                    ['$ref' => self::SCHEMA_PATH_PREFIX.'.jsonld-connector.output_MS_GRAPH'],
                ],
                'discriminator' => [
                    'propertyName' => 'type',
                    'mapping' => [
                        DatasyncConnectorType::SCIM->value
                        => self::SCHEMA_PATH_PREFIX.'.jsonld-connector.output',
                        DatasyncConnectorType::JSON->value
                        => self::SCHEMA_PATH_PREFIX.'.jsonld-connector.output',
                        DatasyncConnectorType::MS_GRAPH->value
                        => self::SCHEMA_PATH_PREFIX.'.jsonld-connector.output_MS_GRAPH',
                    ],
                ],
            ],
        ],
    ]])),
])),
Lingua principale
PHP
Stelle
2.6k
Fork
989
Merge medio
2g 1h
PR unite (30g)
104

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di api-platform/core

Tutte le issue di api-platform/core

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.