Description
Describe the bug
When nested oneOf are used with types that do not match, the resolution fails.
This is somewhat related to #214, but contrary to the oneOf using two distinct object references in:
https://github.com/cwacek/python-jsonschema-objects/blob/master/test/test_regression_214.py#L28-L33
... the nested oneOf also uses different types (as the parent one does in https://github.com/cwacek/python-jsonschema-objects/blob/master/test/test_regression_214.py#L17-L21).
Example Schema and code
I reused the existing test with slight modifications to demonstrate the issue.
master...fmigneault:python-jsonschema-objects:nested-oneOf-regression-example
Expected behavior
As demonstrated with jsonschema.validate (master...fmigneault:python-jsonschema-objects:nested-oneOf-regression-example#diff-8af35489f471b9a4a568c247e1bc375c74c9d577e540975ef8fab8d5feae8575R81), the schema is valid.
It is expected that each combination of
obj1 = ns.MainObject(**{"location": 2}) # FAIL!
obj2 = ns.MainObject(**{"location": {"type": "Location2"}})
obj3 = ns.MainObject(**{"location": "unique:12"})Would resolve to the appropriate type/schema without error.
A quick workaround that lets the resolution succeed is to move the Location1 (number) reference under the parent oneOf. In this case, it resolves correctly (just like UNIQUE_STRING did). However, because of specific schema definitions and references used elsewhere in by actual schema, it cannot be moved like so, and must remain in the nested oneOf.