Confluent's Schema Registry defined several compatiblity levels, which are richer than the compatibility checks that Avro provides.
However, although I understand the definitions for each compatibility level, I don't understand what sequence of schemas could be "fully compatible" but not "fully transitively compatible".
Could anyone provide an example of a sequence of schemas that fits that criteria?
The effect that transitive has is that it'll check all previous versions rather than only the current against the next inserted version.
I wouldn't call this "richer" per-say (the schema registry is still using the same Avro compatibility methods behind the scenes), it just is an improvement over the implicit transitivity that happens if you don't override the configuration in between two versions. (If v2 is compatible with v1, then v3 is compatible to v2, then you would assume v3 is compatible with v1)
I haven't used FULL, but let's say for example, you want to completely break the schema. You could have the default compatibility of BACKWARD (schema v1), then set to NONE and push a schema (v2), then again to BACKWARD. Now, if you push push a new schema (v3), only v2 would be checked against.
If you had set the transitive setting before v3, then v1 would have been checked as well as v2.
Related
The generate multiple files option is not available in the 0.13.0 Settings UI but there is an entry in the ConnectedService.json settings file.
I tried editing the settings file manually and forcing an update but it did not work.
Has this feature been deprecated or is it just broken? I also noticed the custom namespace option did not seem to work either.
This is what shows up in the online documents:
https://learn.microsoft.com/en-us/odata/connectedservice/generating-multiple-files
Another doc shows a different UI...
What my VS 2017/2019 extension shows:
The latest version seems to be version 0.13, the feature seems to be introduced in the OData Connected Service 0.9.1 Release.
The "Generate Multiple Files" option is only available when you're targeting an OData v4 service. This also applies to a few other settings as well. Confirm whether you're targeting an OData v1, v2 or v3 service, if that's the case, that would explain why you're seeing different available options. The docs should be updated to reflect this.
In 3GPP TS 29501, section 6.3, there's information about backwards compatible/incompatible API changes for 5G Core APIs.
What I'm not able to figure out if there's a clear cut rule for request/response payloads? Should a payload always be valid given the NFs version of the API schema for changes to be backwards compatible?
E.g. let's say there's an integer attribute "foo" restricted to values between 0 and 10 in version 1.0.0. If the interval is changed to values between 0 and 20 in a later version, is that considered backwards compatible or not?
If it is considered backwards compatible since 0-10 is covered by 0-20 it means that a consumer should accept values not valid based on it's own API version? (e.g. receiving foo=17).
In the latest version TS 29.501 V17.5.0 Annex B (Informative) Backward Incompatible Changes.
It states "Backward incompatible changes are additions or changes in the API that break the existing Service Consumer behaviour. "
In your example, if the consumer (e.g. UE) uses the new version with "0-20" while the producer (Network Provider) only supports the older version 1.0.0 "0-10", then I think it's not backward compatible bc the producer is unable to support a value larger than 10.
The opposite would be OK, if the older version 1.0.0 was initially "0-20" and then the new version "0-10", it would be covered and considered backward compatible.
Best regards
In the context of C++ toolchain, I am trying to understand the difference of the concept between cc_toolchain_suite and register_toolchains, to me it seems they achieve the same purpose: select a toolchain based on command line parameters.
See https://docs.bazel.build/versions/master/toolchains.html for register_toolchains
See https://docs.bazel.build/versions/master/cc-toolchain-config-reference.html for cc_toolchain_suite
Can someone please help understand the subtlety behind these 2 concepts?
TL;DR The cc_toolchain_suite is part of the legacy toolchain configuration system. It still exists in Bazel because the migration to the new API is not complete. The register_toolchains is part of the newer, unified toolchain API. When possible use register_toolchains instead of cc_toolchain_suite/--*crosstool_top
Originally the concept of a 'toolchain' was not standardised in Bazel, so a Java toolchain would be implemented very differently than a cc toolchain.
Before the unified starlark toolchain API, cc toolchains were specified in proto-text formatted 'CROSSTOOL' files.
With the introduction of the platforms API and the unified toolchains API, the concepts in the CROSSTOOL files were converted almost 1:1 to the new unified platforms/toolchains starlark API. This was mostly to ensure that there was compatibility between the old/new API's.
One of the concepts in the older 'CROSSTOOL' configuration system was a 'toolchain suite', that allowed you to define a group of toolchains targeting different CPU's (This was before the platforms API was introduced).
As far as I understand the only reason that cc_toolchain_suite is still a part of Bazel's starlark API is that some of the apple/android toolchains have not yet been completely migrated across.
Here are a few examples of where I've opted to using the newer register_toolchains approach. Note that these toolchains do not use cc_toolchain_suite anymore.
In upgrading from SCDF 1.1.1.RELEASE to 1.2.4.RELEASE, are there any database schema changes that I would need to be concerned about?
Specifically, if I'm already running SCDF 1.1.1.RELEASE on a Pivotal Cloudfoundry platform, and using a MySQL service tile as the underlying database, will the stream, app, and task metadata that is already in the database translate readily to SCDF upgraded to 1.2.4.RELEASE?
What other potential concerns might I need to take a close look at as I plan to upgrade?
Yes, as documented on the official docs: https://docs.spring.io/spring-cloud-dataflow/docs/1.2.3.RELEASE/reference/htmlsingle/#configuration-rdbms
Apart from the migration-script, there shouldn't be any other concerns wrt upgrade. At least in 1.1 -> 1.2, there's simply a case-conversion of a Task table name, which shouldn't impact existing records or any other functionalities.
That said, 1.2.4 is an old release. Please consider switching over to 1.3 GA release at the earliest. This release includes migration scripts as well, but again, we make sure to not introduce breaking changes in the minor releases (e.g., 1.2 -> 1.3), so switching to 1.3 should be straightforward.
Here's a roundup of all the new features available in the latest 1.3 release.
Errors range from 404s, IOExceptions, or encoding exceptions. They can be buried in the error stack, and occasionally suggest a versioning problem.
How can I prevent or address this class of errors?
The Dataflow service's SDKs and worker take dependencies on common third-party components, which themselves import various dependencies. Version collisions can result in unexpected behavior in the service. If you are using any of these packages in your code, be aware that some libraries are not forward-compatible and you may need to pin to the listed versions that will be in scope during execution. In order to determine whether your JAR has a conflicting version in use, consider inspecting the dependency tree of your project. Consult the list of specifically pinned versions if you suspect a problem here, and also avoid using "latest" for any of these libraries.