Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
Potentially https://www.drupal.org/project/entity_blueprint would make it easier to generate JSON schema for entities. Maybe try it out as a replacement for schemata.
Issue fork ai_migration-3584173
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
dmundraRefinement:
Comment #3
dmundraComment #5
majorrobot commentedIt appears that Entity Blueprint, though it’s more efficient and elegant in its creation of entity/bundle schemas, it cannot produce a JSON Schema.
As Copilot (Claude Opus 4.6) put it, "Entity Blueprint does not have a JSON Schema spec output mode. It only produces its own custom descriptive format (an associative array with entity_type, bundle, fields containing type, label, required, cardinality, etc.). There is no method, flag, or alternate mode that generates a compliant JSON Schema (draft-04/06/07/2020-12) with $schema, type: "object", properties, required, etc."
I've created an issue in Entity Blueprint for a JSON Schema mode. We'll see what happens.
Here was CoPilot's recommendation:
"Write a thin converter in your module that takes Entity Blueprint's schema array and transforms it into a JSON Schema spec. The structure is predictable — you'd map each field's type/cardinality/properties/required to JSON Schema equivalents. This would let you use Entity Blueprint as the source of truth while still feeding a proper JSON Schema to the structured output API."
So, I let AI take a shot at it. It did ok. Then I noticed that it didn't do any recursion, so I had it take a second pass.
What it came up with may work (with some tweaking), but now we've got a converter service that is around 500 lines long and does a lot of what our extensions of Schemata already do. So, what is Entity Blueprint gaining for us now? Not a ton. We could easily co-opt its strategy into our converter and make our converter an independent SchemaCreator class.
So, here are our choices:
1. Stick with Schemata and our custom Normalizers which likely need some work:
- src/Normalizer/jsonapi/AiMigrationSchemaNormalizer.php
- src/Normalizer/jsonapi/RelationshipFieldDefinitionNormalizer.php
2. Switch to Entity Blueprint and use its simpler schema format ... which will not ultimately be friendly with AI API structure output.
3. Switch to Entity Blueprint and use a Converter class like I just had CoPilot create.
4. Remove Entity Blueprint, add some logic to our Converter class, and have our own formatter, with no custom modules.
I've pushed up what I have so far.
I'd be curious to get some feedback on this.
Comment #6
dmundraThank you @majorrobot, I can try to take a shot at looking at the code and giving feedback, probably tomorrow.
Comment #7
dmundraComment #9
dmundraI am confused. The module page mentions this
So it is generating YAML instead of JSON for JSON schemas?
We should focus on the end goal of using structured output and that it relies on JSON schema. So we want to use whatever tool can consistently take any entity type and generate that schema that the models are requiring. So we would be doing what you are doing in this example. Converting generated schema (from whichever tool) into a schema that are compliant with the models.
Looks like schemata might not be maintained so might be worth switching to entity blueprint so we could build it out more?
Comment #10
dmundraFYI I created a draft MR just to see what the pipeline says and also if I had any code comments. Don't have any, code changes look good. I have not QA'd it though. Looks like one small test failure.