การกำหนด Namespace ให้กับ Schema
ทำให้ Type และ Interface ทั้งหมดที่ Plugin เพิ่มเข้าไปใน Schema ได้รับการกำหนด Namespace โดยอัตโนมัติ
การกำหนด Namespace ให้กับ Schema ช่วยหลีกเลี่ยงความขัดแย้งของชื่อ ซึ่งเกิดขึ้นเมื่อเจ้าของต่างกัน (เช่น ทีมงานต่างกันในบริษัท หรือระหว่าง Plugin ของบุคคลที่สาม) ใช้ชื่อเดียวกันสำหรับ Type หรือ Interface
ตัวอย่างเช่น สมมติว่าบริษัท "AwesomeWP" มีทีม Tutorials และทีม Sales และทั้งสองทีมสร้าง Type Product สำหรับ GraphQL Schema ของบริษัท ทำให้เกิดความขัดแย้ง
เมื่อกำหนด Namespace ให้กับ Schema ทั้งสอง Type จะถูกแปลงโดยอัตโนมัติเป็น AwesomeWPTutorialsProduct และ AwesomeWPSalesProduct ซึ่งหลีกเลี่ยงความขัดแย้งโดยไม่ต้องแก้ไข Schema ด้วยตนเอง หรือต้องให้ทีมงานติดต่อประสานงานกัน
Entity จาก WordPress Data Model ไม่มีการกำหนด Namespace
WordPress Data Model ถือเป็นมาตรฐาน และ Type ของ GraphQL Schema (เช่น Post และ User) รวมถึง Interface (เช่น Commentable และ WithMeta) จะไม่มีการกำหนด Namespace
การกำหนด Namespace ให้กับ Schema ใน Endpoint
มี 2 ระดับที่สามารถกำหนดได้ว่า Schema จะมีการกำหนด Namespace หรือไม่ เรียงตามลำดับความสำคัญ:
1. บน Schema Configuration
การกำหนด Namespace ให้กับ Schema สำหรับ Custom Endpoint หรือ Persisted Query สามารถกำหนดได้ผ่าน Schema Configuration ที่เกี่ยวข้อง:

2. โหมดเริ่มต้น กำหนดใน Settings
หาก Schema Configuration มีค่า "Default" ระบบจะใช้โหมดที่กำหนดใน Settings:

การแสดงภาพ Schema ที่มี Namespace
ใช้ Voyager client เพื่อแสดงภาพ Schema ที่มีการกำหนด Namespace
เมื่อปิดใช้งาน Namespace WordPress Schema จะแสดงดังนี้:

เมื่อเปิดใช้งาน Type และ Interface ที่ Plugin เพิ่มเข้ามาจะมีการกำหนด Namespace และแสดงดังนี้:

การ Queries ชื่อ Type ที่มี (หรือไม่มี) Namespace
เมื่อเปิดใช้งาน Namespace แล้ว Type สามารถ Queries ได้โดยใช้ทั้งชื่อ Type ที่มี Namespace และไม่มี Namespace ดังนั้นจึงต้องแก้ไขเฉพาะ Queries ที่เกี่ยวข้องกับ Type ที่ขัดแย้งกันเท่านั้น ไม่ใช่ทั้งหมด
ตัวอย่างเช่น หากทีม Sales ของ AwesomeWP มี Type Discount ด้วย Queries ที่ขอชื่อ Type นี้ยังคงทำงานได้:
query {
discounts {
...DiscountProps
}
}
fragment DiscountProps on Discount {
price
dateRange
}เฉพาะ Type ที่ขัดแย้งกันอย่าง Product เท่านั้นที่ต้องอัปเดตเป็น AwesomeWPSalesProduct ใน Queries เพื่อลบความคลุมเครือ:
query {
products {
...ProductProps
}
}
fragment ProductProps on AwesomeWPSalesProduct {
price
dateRange
}GraphQL Spec
ฟังก์ชันนี้ยังไม่ได้เป็นส่วนหนึ่งของ GraphQL Spec แต่มีการร้องขอใน: