allOf is not properly merged

Given a schema that uses allOf to combine two different object schemas, the properties of the two schemas are not combined:

{
  "components": {
    "schemas": {
      "identifier": {
        "type": "object",
        "properties": {
           "id": {"type": "string"}
        }
      },
      "person": {
        "allOf": [
          {"$ref": "#/components/schemas/identifier"},
          {
            "type": "object",
            "properties": {
              "name": {
                "type": "string"
              }
            }
          }
        ]
      }
    }
  }
}

Not 100% sure that schema validates, but it should be a good start.

added test for reading schema with "allOf"

Hi, thanks for the report, could you elaborate on how you read the schema and what you expect in the output. I added a test for your Schema (b9eddbd) and as far as I see everything is loaded correctly.

I believe the resolved reference should include both the id and name properties; something like:

assert($resolvedRef->type === 'object');
assert($resolvedRef->properties->id->type === 'string');
assert($resolvedRef->properties->name->type === 'string');

When I tried to use https://github.com/lezhnev74/openapi-psr7-validator it gave me errors with any schema that used allOf, stating that it couldn't find the (combined) properties.

The purpose of php-openapi is to read and write OpenAPI description files as they are, so you get the raw allOf element with its sub-schemas only. For schema validation you need to use other tools (at least now this is not implemented). The validation of the request schema against the API description has to be made by lezhnev74/openapi-psr7-validator which should validate the request based on allOf semantics.

@lezhnev74

ping @lezhnev74

Hey! Ok, this looks like a problem with resolving references. Let me try to write a failing test first.

I've added this test which validates a response body against a schema with a reference:

a test
a schema and a reference

The validator builds a schema in the memory and resolves all the references automatically.
You can access resolved schema like this:

$schema = $validator->getSchema();
$allOf = $schema->paths['/ref']->post->responses['200']->content['application/json']->schema->allOf;
var_dump($allOf[0]->properties['age']->type); // "integer"
var_dump($allOf[1]->properties['name']->type); // "string"

@cebe

@cebe as I understand, one can resolve references manually like this:

use cebe\openapi\Reader;
use cebe\openapi\ReferenceContext;
use function realpath;


$filePath = "./schema.yaml";
$schema = Reader::readFromYamlFile($filePath);
$schema->resolveReferences(new ReferenceContext($schema, realpath($filePath)));

resolveReferences() is called automatically by default, so the reference should not be a problem:

$resolveReferences parameter defaults to true:

php-openapi/src/Reader.php

Lines 93 to 100 in 13b9175

    
           public static function readFromYamlFile(string $fileName, string $baseType = OpenApi::class, $resolveReferences = true): SpecObjectInterface 
        
           { 
        
               $spec = static::readFromYaml(file_get_contents($fileName), $baseType); 
        
               $spec->setReferenceContext(new ReferenceContext($spec, $fileName)); 
        
               if ($resolveReferences) { 
        
                   $spec->resolveReferences(); 
        
               } 
        
               return $spec;

Hi, version 1.3.0 fixes a lot of issues with references, please try if this is solved by the changes.

Closing this issue for now, please comment if the issue persists. I'll reopen it then.

@cebe

@cebe We're still seeing this issue.

allOf components are not resolving correctly.

You can see the attached issue here: hotmeteor/spectator#38

@hotmeteor

@hotmeteor I see hotmeteor/spectator#38 (comment) is closed now, is there still something to fix in cebe/php-openapi or was this only a problem in your tool?

No, there's still an issue. I created a workaround in my tool, but I'd prefer to see things merging as expected. This is the example schema that we're testing with: https://github.com/hotmeteor/spectator/blob/master/tests/Fixtures/Components.v1.json

@cebe

@cebe I forgot I had reported this issue, so I had created another ticket here: #120

It can be closed, but it does contain some useful information for testing.

still not really sure what this is about. Could someone come up with a failing test case for this?

This issue is fixed in #208

Until merged, this PR can be 'composer required' as documented at https://github.com/php-openapi/yii2-openapi/blob/master/CONTRIBUTING.md#use-pr-of-your-own-fork-of-this-library-in-your-project-to-check-new-changes

Usage:

$openApi = Reader::readFromYamlFile(__DIR__ . '/path-to-spec.yml', \cebe\openapi\spec\OpenApi\OpenApi::class, true, true);

Navigation Menu

Repository navigation

allOf is not properly merged #31

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

	public static function readFromYamlFile(string $fileName, string $baseType = OpenApi::class, $resolveReferences = true): SpecObjectInterface
	{
	$spec = static::readFromYaml(file_get_contents($fileName), $baseType);
	$spec->setReferenceContext(new ReferenceContext($spec, $fileName));
	if ($resolveReferences) {
	$spec->resolveReferences();
	}
	return $spec;

allOf is not properly merged #31

Description

Activity

cebe commented on Jul 30, 2019

shadowhand commented on Aug 1, 2019

cebe commented on Aug 7, 2019

cebe commented on Aug 7, 2019

lezhnev74 commented on Aug 8, 2019

lezhnev74 commented on Aug 8, 2019

lezhnev74 commented on Aug 8, 2019

cebe commented on Aug 9, 2019

cebe commented on Oct 28, 2019

cebe commented on Feb 28, 2020

hotmeteor commented on Apr 21, 2021

cebe commented on Apr 23, 2021

hotmeteor commented on Apr 23, 2021

hotmeteor commented on Jul 24, 2021

cebe commented on Oct 13, 2021

SOHELAHMED7 commented on Jan 25, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions