Hi,
I have a multiple schema.json (public and protected query) and I export two file schema.json but I don't found the RunScript for add multiple schema.json into one file API.swift
I try with multiple RunScript but not work (I found only the content of the last schema.json)
Thanks
SCRIPT_PATH="${PODS_ROOT}/Apollo/scripts"
cd "${SRCROOT}/${TARGET_NAME}"
"${SCRIPT_PATH}"/run-bundled-codegen.sh codegen:generate --target=swift --includes=./*/.graphql --localSchemaFile="schema.json" API.swift
cd "${SRCROOT}/${TARGET_NAME}"
"${SCRIPT_PATH}"/run-bundled-codegen.sh codegen:generate --target=swift --includes=./*/.graphql --localSchemaFile="schema2.json" API2.swift
Since our codgen supports comma-separated values for localSchemaFile, you should be able to pass --localSchemaFile="schema.json","schema2.json" and have that output a single file.
Note: I'm not 100% sure on the placement of quotes, but a comma-delimited list is definitely supported. Let me know if this works for you.
Tnx @designatednerd I try but I have the error when build with run script
Command PhaseScriptExecution failed with a nonzero exit code
Showing Recent Messages
{ Error: Error in "Loading schema for Unnamed Project": GraphQLSchemaValidationError: Must provide only one schema definition.
There can be only one type named "activityAssignedTypeType".
etc....
Thanks
The schema validation error seems weird given that we're supporting a comma separated list of schemas. Checking in with the tooling team on that.
The question I have is whether there's any overlap between the two schemas. That could be causing the There can only be one type named... error (which mayyyybe is kicking back up to that other error?).
Yes,
we have the same type in the schema (is it also right no?)
This is my Run Script
SCRIPT_PATH="${PODS_ROOT}/Apollo/scripts"
cd "${SRCROOT}/${TARGET_NAME}"
"${SCRIPT_PATH}"/run-bundled-codegen.sh codegen:generate --target=swift --includes=./*/.graphql --localSchemaFile="schema.json","schema2.json" API.swift
If two schemas have the same types, that's going to cause confusion for the code generation - it doesn't do de-duplication. The multiple schemas thing is more for people who are getting schemas from totally different places (eg, different microservices) where there would be no overlap in the schema.
I guess it's worth backing up and asking: Why do you need two schemas?
@designatednerd we have two end points, first schema is protected ,and first query need authorized token, second schema is public ,and second query don't need authorized token
I'm confused as to why both schemas have the same types defined. In theory if you've got two schemas, they should be non-overlapping.
If they're overlapping, then I'm confused about why they're separate in the first place. If these are hitting the same service, the requirement for an auth token should be able to be enforced by "middleware" - ie, code on your server that checks whether authentication is required before going and doing any fetching.
In terms of getting y'all unblocked, you can try setting up each schema and the queries to it in separate folders, and then instead of cd "${SRCROOT}/${TARGET_NAME}" you cd into each folder with the schema and run the codegen there. If there's overlap you may also need to add a namespace - you can do that with the --namespace flag. Each of the two files would need a different namespace.
@freedoom1984 @cczufish did this help?
I also encountered the same problems and errors. I don't know what to do
@guoxiaopang Can you elaborate a bit:
@guoxiaopang Can you elaborate a bit:
- Are your schemas overlapping?
- Are you passing them both into the same command or into separate commands?
- Are you using a namespace?
I don't know how the client uses namespace.
If you're not using the --namespace flag you're not using namespaces - it basically wraps everything in a giant enum so that you can namespace different things the same way.
It looks from that error like the issue is that there's overlap in the schema - a type called Query is defined in both of them, so they can't be reduced down to a single schema. My suggestion would be basically the same as here - you'll probably need to generate two different files which each uses a different namespace, and each takes a single schema when you generate it.
OK I'm going to close this out since I haven't heard anything back here. The TL;DR of the recommendations here:
Passing multiple schema.json files to the --localSchemaFile parameter is only possible if your schemas are non-overlapping. This means nothing in either schema file can be defined in the other schema file.
This is generally only the case if you have a really, really, really gargantuan schema.json file at a large corporation that was separated into separate pieces for easier or parallel download.
If you have two overlapping schema files, you should be able to use a single cd command and then two different codegen:generate commands one after the other in order to generate two files with generated code.
You must make sure the file each command outputs two is different, otherwise the second command will overwrite the file created in the first.
--namespace flag if you're planning to do this, which wraps all the queries etc in an outer enum so you can more easily distinguish between which queries are associated with which schema.
Most helpful comment
OK I'm going to close this out since I haven't heard anything back here. The TL;DR of the recommendations here:
Passing multiple
schema.jsonfiles to the--localSchemaFileparameter is only possible if your schemas are non-overlapping. This means nothing in either schema file can be defined in the other schema file.This is generally only the case if you have a really, really, really gargantuan
schema.jsonfile at a large corporation that was separated into separate pieces for easier or parallel download.If you have two overlapping schema files, you should be able to use a single
cdcommand and then two differentcodegen:generatecommands one after the other in order to generate two files with generated code.You must make sure the file each command outputs two is different, otherwise the second command will overwrite the file created in the first.
--namespaceflag if you're planning to do this, which wraps all the queries etc in an outerenumso you can more easily distinguish between which queries are associated with which schema.