Allow Children of Children Versions of the same Schema

[mattBrzezinski]

Overview

Stemming from an internal discussion w/ @haberdashPI I was wanting to create a V2 schemaversion off of its V1 schemaversion. It wasn't clear why this is disallowed? This PR loosens the constraint and allows for this situation.

using Legolas
using Legolas: @schema, @version

@schema "foo.bar" Bar

@version BarV1 begin
    a
end

@version BarV2 > BarV1 begin
    b
end

[omus]

This feels a little weird. I suspect this may be problematic with the addition of multiple inheritance.

Is the main motivation here to avoid having to copy the entirety of the previous schema version? If so I could see a convenience syntax to do that without having to utilize the inheritance system. For example with this PR if BarV1 had a parent and in BarV2 you wanted to modify the parent as well as copy the fields from BarV1 you couldn't do that.

[mattBrzezinski]

This feels a little weird. I suspect this may be problematic with the addition of multiple inheritance.

Is the main motivation here to avoid having to copy the entirety of the previous schema version? If so I could see a convenience syntax to do that without having to utilize the inheritance system. For example with this PR if BarV1 had a parent and in BarV2 you wanted to modify the parent as well as copy the fields from BarV1 you couldn't do that.

Currently we have something like,

using Legolas: @schema, @version

@schema "foo.general" General

@version GeneralV1 begin
    general_field
end

@schema "foo.bar" BarV1

@version BarV1 > GeneralV1 begin
    bar_field
end

I want to introduce a new field to BarV1, however I do not want to tag a breaking change as we will be making a few of these changes in the future. To get around this the idea is to walk around semver for the package and introduce a new schema version,

@schema BarV2 > BarV1 begin
    new_field
end

From there we can tag a non-breaking release, warning users however to continue using BarV1 until all work is complete on BarV2. Then deprecating BarV1, tagging that release. And then making a new release where BarV1 is removed and usage is only through BarV2.

Making a breaking change isn't that problematic on its own, but current internal work will require modifying a few schema versions some of which requires some design work. I'm really trying to avoid the situation of making multiple breaking change releases in a short amount of time and causing some roughness with users of the package where BarV1 is being defined.

[ericphanson]

And then making a new release where BarV1 is removed and usage is only through BarV2.

This is not possible with this design:

julia> using Legolas

julia> using Legolas: @schema, @version

julia> @schema "foo.bar" Bar

julia> @version BarV1 begin
           a
       end

julia> @version BarV2 > BarV1 begin
           b
       end

julia> Legolas.identifier(BarV2SchemaVersion())
"foo.bar@2>foo.bar@1"

Legolas.identifier gets serialized into Legolas-produced tables, as the identifier for the schema, meaning to load such a table, the loader must have acess to the foo.bar@2 and foo.bar@1 schemas. Therefore, with this route, foo.bar@1 can never be removed as long as foo.bar@2 is supported.

I second @omus in that you should just copy-paste, and we could automate that with a macro if really needed. That is, define

using Legolas
using Legolas: @schema, @version

@schema "foo.bar" Bar

@version BarV1 begin
    a
end

@version BarV2 begin
    a
    b
end

Then when you no longer need BarV1, you can remove it without touching the BarV2 schema. (And there is no need for a breaking change if you don't need it; you can leave the BarV1 schema for as long as you like).

To get around this the idea is to walk around semver for the package and introduce a new schema version

BTW this is not getting around package semver, in fact, this is one reason why schemas have versions! I.e. this is the intended use of Legolas.jl.