Add ability to get subschemas of CombinedSchema in insertion order #519
Conversation
|
Hello @rayokota I thought you already migrated to erosb/json-sKema, didn't you? |
|
Hi @erosb , we still use this library for the older drafts, and also for the object model it provides. |
|
Hello @rayokota does this issue have an originator issue in the schema registry GH repo? Or can you point me to any source where the current behavior causes a problem? |
|
Thanks @erosb , I've filed confluentinc/schema-registry#3536 to track. I'm happy to answer any further questions you might have. |
|
Hi @erosb , do you have any more feedback/questions on this PR? |
|
Hello @rayokota I'm thinking about if it is possible to fix this issue without introducing an other public method on CombinedSchema. I pushed a commit into a separate branch, trying to implement a comparator which remembers the original ordering of subschemas, but so far it doesn't work (the |
Maintain insertion order for subschemas of CombinedSchema. This is an alternative to #519 that maintains the subschemas in insertion order. The subschemas were originally maintained in insertion order, but it was changed due to #405, which ensured that subschemas that were of type CombinedSchema were visited first during validation, and by #498, which tries to maintain a stable order for "equivalent" instances. This PR simply restores the insertion order, but maintains an internally sorted collection for the two purposes listed above, namely visiting subschemas during validation and equivalence checks during equals/hashCode.
Add the ability to get subschemas of CombinedSchema in insertion order.
For context, the code in Confluent Schema Registry is currently using version 1.14.3 of this library. We found that when we upgraded to 1.14.4 some of our code no longer worked because we were relying on the order of schemas returned from
CombinedSchema.getSubschemas(). That order changed in 1.14.4 due to #498. It turns out the order was not deterministic anyway for the leading subschemas, but we hadn't yet hit this problem. But now while the order is deterministic for any one specific JVM execution, it may be different between different executions and different JVMs because it uses thehashCodemethod to sort the subschemas.Our code works best with the insertion order, which is deterministic (across executions and JVMs) for a given
CombinedSchema. Therefore a modest workaround that works for us is to add aCombinedSchema.getOrderedSubschemasmethod and for the Confluent code to rely on that method instead ofCombinedSchema.getSubschemas.