Change Details

With the rise of heterogeneous consumers of the journal (esp. mirrors), we really need to start advertise schema versions in the journal, which means we need to declare schema version in the schema itself. This could be a global parameter of the while schema (but the problem is we (may?) have several schemas for related features that are not in swh-schema), or it could be a per-entity parameter. This later solution would make the compat code a bit easier to handle (only deal with actual evolution of the concerned object type), I think, and make the "which schema" a non-question (maybe?). Related to T3890 for example.

With the rise of heterogeneous consumers of the journal (esp. mirrors), we really need to start advertise schema versions in the journal, which means we need to declare schema version in the schema itself. This could be a global parameter of the while schema (but the problem is we (may?) have several schemas for related features that are not in swh-schema), or it could be a per-entity parameter. This later solution would make the compat code a bit easier to handle (only deal with actual evolution of the concerned object type), I think, and make the "which schema" a non-question (maybe?). Related to T3890 for example, and T1279.

With the rise of heterogeneous consumers of the journal (esp. mirrors), we really need to start advertise schema versions in the journal, which means we need to declare schema version in the schema itself. This could be a global parameter of the while schema (but the problem is we (may?) have several schemas for related features that are not in swh-schema), or it could be a per-entity parameter. This later solution would make the compat code a bit easier to handle (only deal with actual evolution of the concerned object type), I think, and make the "which schema" a non-question (maybe?). Related to T3890 for example, and T1279.