oneOf filter

[juneidy]

A question regarding oneOf in filter operation.
Given the example

const validator = require('is-my-json-valid');

const schema = {
	type : 'object',
	additionalProperties : false,
	properties : {
		bar : {
			type : 'object'
		},
		baz : {
			type : 'object'
		}
	},
	oneOf : [{
		properties : {
			bar : {
				type : 'object',
				additionalProperties : false,
				properties : {
					a : {
						type : 'array',
						items : {
							type : 'number'
						}
					}
				}
			},
			baz : {
				type : 'object',
				additionalProperties : false,
				properties : {
					z : {
						type : 'object'
					}
				}
			}
		}
	}, {
		properties : {
			bar : {
				type : 'object',
				additionalProperties : false,
				properties : {
					a : {
						type : 'array',
						items : {
							type : 'number'
						}
					},
					b : {
						type : 'array',
						items : {
							type : 'number'
						}
					}
				}
			},
			baz : {
				type : 'object',
				additionalProperties : false,
				properties : {
					y : {
						type : 'object'
					}
				}
			}
		}
	}]
};

const obj = {
	bar : {
		a : [1],
		b : [1]
	},
	baz : {
		z : {}
	}
};

const filter = validator.filter(schema);
const validate = validator(schema);

console.log(filter(obj));
// { bar: { a: [ 1 ], b: [ 1 ] }, baz: { z: {} } }

validate(obj);

console.log(validate.errors);
//[ { field: 'data',
//  message: 'no (or more than one) schemas match' } ]

It seems that filter ignores the oneOf completely.
Is this an expected behaviour?

[sid-360]

I see no one responded to the above query. By any chance were you able to figure out what was the issue? I am currently working on a conditional validation of sub-schemas and would like to be aware of any issues/observations around oneOf, as I would certainly be using it for my use case. Thanks

[thetumper]

I don't think any matches. Your object has a bar that matches the bar in the first schema in the oneOf, but has a baz that matches the baz sub-schema in the second schema in the oneOf.

E.g., either of these should work: { bar: { a: [1] }, baz: { z: {} } } or { bar: { a: [1], b: [1]}, baz: { y: {} }}

[juneidy]

I see no one responded to the above query. By any chance were you able to figure out what was the issue? I am currently working on a conditional validation of sub-schemas and would like to be aware of any issues/observations around oneOf, as I would certainly be using it for my use case. Thanks

If all you care is validating with oneOf, I think you're fine. The problem I stipulated is filter operation.

I don't think any matches. Your object has a bar that matches the bar in the first schema in the oneOf, but has a baz that matches the baz sub-schema in the second schema in the oneOf.

E.g., either of these should work: { bar: { a: [1] }, baz: { z: {} } } or { bar: { a: [1], b: [1]}, baz: { y: {} }}

I know the object doesn't match the schema, in fact I purposefully made it so to test the filter. Had the filter perform the operation taking into account of the oneOf, the validation that follows (in the example) would pass without error.

[thetumper]

If I'm understanding how filter works, you'd have to first match a schema. Because you're not, there's nothing to filter. So, the filter does seem to be taking into account the oneOf -- but the result is "filter based on (no schema)" --> i.e., filter nothing. Make sense?

[juneidy]

If I'm understanding how filter works, you'd have to first match a schema. Because you're not, there's nothing to filter. So, the filter does seem to be taking into account the oneOf -- but the result is "filter based on (no schema)" --> i.e., filter nothing. Make sense?

Not quite sure. But if what you say is you need to match the schema to filter, then what is the purpose of filter? If I understand correctly, filter is to strip out properties that does not match the schema. Under normal circumstances that is the case. But why not oneOf?

If oneOf filter requires your object to match one of the schema, then there is nothing to filter too, because the resulting object would be the same anyway since it already match one of the schema.