Fix for handling nested patch level version upgrade.

Fixes #157 (closed). from @akumar290

The current schema validation works with respect to neighboring versions that exists in the system. For example, if the system started evolving from osdu:wks:wellbore:1.0.0 and there does not exist any other neighbor, in that case any changes to this schema kind is possible ie you can add or remove any attribute from this kind.

On the other hand, if system already has below kinds:

• osdu:wks:wellbore:1.0.1
• osdu:wks:wellbore:1.0.4

and user wants to introduce a new version osdu:wks:wellbore:1.0.3, in that case the comparison of 1.0.3 will happen with both versions ie 1.0.1 and 1.0.4.

So, it is not true that user cannot make version lower than what already exists in the system.

Coming to the original root cause of the issue. The validation of schema service fails when there is $ref change at second level. For example:

This issue has previously occurred in the past but at that time the fix was applied only for the MINOR version level

MR: OSDU-DD-M12-Delivery (!301) · Merge requests · OSDU Software / OSDU Data Platform / System / Schema · GitLab (opengroup.org)

I have tested the fix locally and it is working fine.

added 1 commit

• a717dcf0 - adding junit and modifying a logic

Compare with previous version

added Common Code MRBugfix labels

changed milestone to %M23 - Release 0.26

changed the description

mentioned in merge request !668 (closed)

mentioned in merge request !667 (closed)

added 1 commit

• 46dab3fa - Fixing load_sequence.1.0.0.json

Compare with previous version

Hello @akumar290,

Can you please add some details to the changes included in this MR. It will be good for understanding in the future.

it would work for scenarios 2.0.0 to 2.0.1. can we also check for 2.1.0 and 2.1.1? from logic, it looks like it shall support. @deepapathak please check and approve if these scenarios are not issues. CC: @chad

changed the description

approved this merge request

There are some failures in azure run for this scenario:

Verify that Schema Service's POST API responds as bad request when main schema is incremented at patch level and entity name is changed in $ref

We are checking to see if its related to the changes, can we please wait till we confirm this?

approved this merge request

merged

mentioned in commit cd36e238

mentioned in merge request !670 (merged)

resolved all threads