含嵌套数组的JSON Schema定义咨询及代码修正请求
Hey there! No worries at all about being new to JSON Schema—we’ve all started out figuring this stuff out. Let’s break down the issues in your schema and get it sorted step by step.
First, the Critical Structural Bug
The biggest problem is that your Accounts array is placed outside the properties object for each customer. In JSON Schema, all properties of an object must live inside the properties field. Right now, Accounts is a sibling to properties, which means validators won’t recognize it as part of the customer’s structure. That’s why your nested account setup wasn’t working as expected.
Small Tweaks for Accuracy
- For
customerid_cl, you wrote"minimum": 000000000—in JSON, leading zeros in numbers are ignored, so this is actually equivalent to0. If you need this to be a 9-digit integer, setminimum: 100000000(the smallest 9-digit number) to pair with your existingmaximum: 999999999. If leading zeros are allowed (like000123456), switch the type tostringand use a regex pattern:"pattern": "^\\d{9}$". - The
format: "decimal"isn’t a standard JSON Schema keyword—it’s an extension supported by some tools. For broad compatibility, you can omit it; just keepingtype: "number"with your min/max values will work perfectly for negative balances.
Handling Negative currentbalance Values
You actually had this part right! Setting "minimum": -999999999.99 explicitly allows negative values down to that threshold. That configuration is correct—you just needed to fix the structural issues around it.
Revised Working Schema
{ "type": "object", "properties": { "customers": { "description": "Contains up to 5 customers", "type": "array", "maxItems": 5, "minItems": 0, "items": { "type": "object", "properties": { "customerid_cl": { "description": "ID-KUNDNR", "type": "integer", "maximum": 999999999, "minimum": 100000000 // Enforces 9-digit integer (adjust if leading zeros are allowed) }, "ssn_number": { "description": "id_persnr", "type": "string", "maxLength": 12, "minLength": 12 }, "first_name": { "description": "be_fnamn", "type": "string", "maxLength": 15, "minLength": 15 }, "last_name": { "description": "be_enamn", "type": "string", "maxLength": 27, "minLength": 27 }, "deceased": { "description": "FL-AVLIDEN", "type": "boolean" }, "accounts": { // Moved inside customer properties, lowercase for consistency "description": "Contains up to 40 account types", "type": "array", "maxItems": 40, "minItems": 0, "items": { "type": "object", "properties": { "account_number": { "description": "id_kontonr", "type": "string", "maxLength": 9, "minLength": 1 }, "currentbalance": { "description": "Current account balance - negative values are allowed", "type": "number", "maximum": 999999999.99, "minimum": -999999999.99 } } } } } } } } }
Key Changes Recap
- Moved
accountsinto the customer’spropertiesobject so validators recognize it as a valid customer attribute. - Fixed
customerid_cl’s minimum value to properly enforce 9-digit integers (adjust if your requirements allow shorter numbers or leading zeros). - Removed the non-standard
format: "decimal"for broader tool compatibility (add it back if your validator supports it). - Lowercased
Accountstoaccountsto match the camelCase style of your other properties (optional, but consistency makes the schema easier to read).
内容的提问来源于stack exchange,提问作者Michael Simpson

