[Linear cache] Increase mutualization between delta and sotw in linear cache to have behavior driven logic instead #14
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
valerian-roche
force-pushed
the
vr/linear-sotw-stable-versions
branch
from
16f4615 to
ba5d383
Compare
valerian-roche
force-pushed
the
vr/linear-mutualize
branch
from
fb7e1fc to
3e9d997
Compare
valerian-roche
force-pushed
the
vr/linear-sotw-stable-versions
branch
from
ba5d383 to
71686da
Compare
valerian-roche
force-pushed
the
vr/linear-mutualize
branch
from
3e9d997 to
14ceddc
Compare
valerian-roche
force-pushed
the
vr/linear-sotw-stable-versions
branch
2 times, most recently
from
11e1362 to
4c322a7
Compare
valerian-roche
force-pushed
the
vr/linear-mutualize
branch
from
14ceddc to
4e88d3d
Compare
valerian-roche
force-pushed
the
vr/linear-sotw-stable-versions
branch
from
4c322a7 to
8bb7c6b
Compare
valerian-roche
force-pushed
the
vr/linear-mutualize
branch
from
4e88d3d to
c7fe0c6
Compare
…r cache to have behavior driven logic instead Signed-off-by: Valerian Roche <valerian.roche@datadoghq.com>
valerian-roche
force-pushed
the
vr/linear-mutualize
branch
from
c7fe0c6 to
2bf15ef
Compare
valerian-roche
changed the base branch from
vr/linear-sotw-stable-versions
to
dd/sotw-fixes
atollena
approved these changes
Feb 23, 2024
Signed-off-by: Valerian Roche <valerian.roche@datadoghq.com>
valerian-roche
force-pushed
the
vr/linear-mutualize
branch
from
d37e201 to
acd5641
Compare
valerian-roche
added a commit
that referenced
this pull request
Feb 23, 2024
…r cache to have behavior driven logic instead (#14) Following the addition of stable version support in sotw, the remaining differences of behavior between sotw and delta are: - on first request, check the returned version in sotw if activating stable version. Also compute the version differently - in some cases, return full state in sotw. In other case don't return if the only change is deletion - compute the version differently In this context, the code can now be mostly merged, apart from the type differences on requests and responses (which I think can be reduced to none soon, but requires more rework on simple side and would be somewhat backward incompatible). In this PR, the linear cache no longer treats sotw and delta watches differently. They are tracked in the same maps and the changes and responses are computed in a common method. Differences in behavior (e.g. full state or which version to use) is now a functional attribute of the watch itself. There are two main parts not yet fully merged: - changing the version in sotw when using stable versions. The requirement to prepend cache version prefix makes it harder to abstract - defining whether a change only removing resources should trigger a response. This could be made a functional flag but given its intersection with `fullStateResponses` seemed fragile Signed-off-by: Valerian Roche <valerian.roche@datadoghq.com>
zhiyanfoo
pushed a commit
that referenced
this pull request
Apr 10, 2024
…r cache to have behavior driven logic instead (#14) Following the addition of stable version support in sotw, the remaining differences of behavior between sotw and delta are: - on first request, check the returned version in sotw if activating stable version. Also compute the version differently - in some cases, return full state in sotw. In other case don't return if the only change is deletion - compute the version differently In this context, the code can now be mostly merged, apart from the type differences on requests and responses (which I think can be reduced to none soon, but requires more rework on simple side and would be somewhat backward incompatible). In this PR, the linear cache no longer treats sotw and delta watches differently. They are tracked in the same maps and the changes and responses are computed in a common method. Differences in behavior (e.g. full state or which version to use) is now a functional attribute of the watch itself. There are two main parts not yet fully merged: - changing the version in sotw when using stable versions. The requirement to prepend cache version prefix makes it harder to abstract - defining whether a change only removing resources should trigger a response. This could be made a functional flag but given its intersection with `fullStateResponses` seemed fragile Signed-off-by: Valerian Roche <valerian.roche@datadoghq.com>
valerian-roche
added a commit
that referenced
this pull request
Apr 10, 2024
…r cache to have behavior driven logic instead (#14) Following the addition of stable version support in sotw, the remaining differences of behavior between sotw and delta are: - on first request, check the returned version in sotw if activating stable version. Also compute the version differently - in some cases, return full state in sotw. In other case don't return if the only change is deletion - compute the version differently In this context, the code can now be mostly merged, apart from the type differences on requests and responses (which I think can be reduced to none soon, but requires more rework on simple side and would be somewhat backward incompatible). In this PR, the linear cache no longer treats sotw and delta watches differently. They are tracked in the same maps and the changes and responses are computed in a common method. Differences in behavior (e.g. full state or which version to use) is now a functional attribute of the watch itself. There are two main parts not yet fully merged: - changing the version in sotw when using stable versions. The requirement to prepend cache version prefix makes it harder to abstract - defining whether a change only removing resources should trigger a response. This could be made a functional flag but given its intersection with `fullStateResponses` seemed fragile Signed-off-by: Valerian Roche <valerian.roche@datadoghq.com>
valerian-roche
added a commit
that referenced
this pull request
May 9, 2024
…r cache to have behavior driven logic instead (#14) Following the addition of stable version support in sotw, the remaining differences of behavior between sotw and delta are: - on first request, check the returned version in sotw if activating stable version. Also compute the version differently - in some cases, return full state in sotw. In other case don't return if the only change is deletion - compute the version differently In this context, the code can now be mostly merged, apart from the type differences on requests and responses (which I think can be reduced to none soon, but requires more rework on simple side and would be somewhat backward incompatible). In this PR, the linear cache no longer treats sotw and delta watches differently. They are tracked in the same maps and the changes and responses are computed in a common method. Differences in behavior (e.g. full state or which version to use) is now a functional attribute of the watch itself. There are two main parts not yet fully merged: - changing the version in sotw when using stable versions. The requirement to prepend cache version prefix makes it harder to abstract - defining whether a change only removing resources should trigger a response. This could be made a functional flag but given its intersection with `fullStateResponses` seemed fragile Signed-off-by: Valerian Roche <valerian.roche@datadoghq.com>
valerian-roche
added a commit
that referenced
this pull request
Aug 8, 2024
…r cache to have behavior driven logic instead (#14) Following the addition of stable version support in sotw, the remaining differences of behavior between sotw and delta are: - on first request, check the returned version in sotw if activating stable version. Also compute the version differently - in some cases, return full state in sotw. In other case don't return if the only change is deletion - compute the version differently In this context, the code can now be mostly merged, apart from the type differences on requests and responses (which I think can be reduced to none soon, but requires more rework on simple side and would be somewhat backward incompatible). In this PR, the linear cache no longer treats sotw and delta watches differently. They are tracked in the same maps and the changes and responses are computed in a common method. Differences in behavior (e.g. full state or which version to use) is now a functional attribute of the watch itself. There are two main parts not yet fully merged: - changing the version in sotw when using stable versions. The requirement to prepend cache version prefix makes it harder to abstract - defining whether a change only removing resources should trigger a response. This could be made a functional flag but given its intersection with `fullStateResponses` seemed fragile Signed-off-by: Valerian Roche <valerian.roche@datadoghq.com>
shamdor
pushed a commit
that referenced
this pull request
Sep 23, 2024
…r cache to have behavior driven logic instead (#14) Following the addition of stable version support in sotw, the remaining differences of behavior between sotw and delta are: - on first request, check the returned version in sotw if activating stable version. Also compute the version differently - in some cases, return full state in sotw. In other case don't return if the only change is deletion - compute the version differently In this context, the code can now be mostly merged, apart from the type differences on requests and responses (which I think can be reduced to none soon, but requires more rework on simple side and would be somewhat backward incompatible). In this PR, the linear cache no longer treats sotw and delta watches differently. They are tracked in the same maps and the changes and responses are computed in a common method. Differences in behavior (e.g. full state or which version to use) is now a functional attribute of the watch itself. There are two main parts not yet fully merged: - changing the version in sotw when using stable versions. The requirement to prepend cache version prefix makes it harder to abstract - defining whether a change only removing resources should trigger a response. This could be made a functional flag but given its intersection with `fullStateResponses` seemed fragile Signed-off-by: Valerian Roche <valerian.roche@datadoghq.com>
wdauchy
pushed a commit
that referenced
this pull request
Oct 25, 2024
…r cache to have behavior driven logic instead (#14) Following the addition of stable version support in sotw, the remaining differences of behavior between sotw and delta are: - on first request, check the returned version in sotw if activating stable version. Also compute the version differently - in some cases, return full state in sotw. In other case don't return if the only change is deletion - compute the version differently In this context, the code can now be mostly merged, apart from the type differences on requests and responses (which I think can be reduced to none soon, but requires more rework on simple side and would be somewhat backward incompatible). In this PR, the linear cache no longer treats sotw and delta watches differently. They are tracked in the same maps and the changes and responses are computed in a common method. Differences in behavior (e.g. full state or which version to use) is now a functional attribute of the watch itself. There are two main parts not yet fully merged: - changing the version in sotw when using stable versions. The requirement to prepend cache version prefix makes it harder to abstract - defining whether a change only removing resources should trigger a response. This could be made a functional flag but given its intersection with `fullStateResponses` seemed fragile Signed-off-by: Valerian Roche <valerian.roche@datadoghq.com>
wdauchy
pushed a commit
that referenced
this pull request
Oct 25, 2024
…r cache to have behavior driven logic instead (#14) Following the addition of stable version support in sotw, the remaining differences of behavior between sotw and delta are: - on first request, check the returned version in sotw if activating stable version. Also compute the version differently - in some cases, return full state in sotw. In other case don't return if the only change is deletion - compute the version differently In this context, the code can now be mostly merged, apart from the type differences on requests and responses (which I think can be reduced to none soon, but requires more rework on simple side and would be somewhat backward incompatible). In this PR, the linear cache no longer treats sotw and delta watches differently. They are tracked in the same maps and the changes and responses are computed in a common method. Differences in behavior (e.g. full state or which version to use) is now a functional attribute of the watch itself. There are two main parts not yet fully merged: - changing the version in sotw when using stable versions. The requirement to prepend cache version prefix makes it harder to abstract - defining whether a change only removing resources should trigger a response. This could be made a functional flag but given its intersection with `fullStateResponses` seemed fragile Signed-off-by: Valerian Roche <valerian.roche@datadoghq.com>
wdauchy
pushed a commit
that referenced
this pull request
Oct 25, 2024
…r cache to have behavior driven logic instead (#14) Following the addition of stable version support in sotw, the remaining differences of behavior between sotw and delta are: - on first request, check the returned version in sotw if activating stable version. Also compute the version differently - in some cases, return full state in sotw. In other case don't return if the only change is deletion - compute the version differently In this context, the code can now be mostly merged, apart from the type differences on requests and responses (which I think can be reduced to none soon, but requires more rework on simple side and would be somewhat backward incompatible). In this PR, the linear cache no longer treats sotw and delta watches differently. They are tracked in the same maps and the changes and responses are computed in a common method. Differences in behavior (e.g. full state or which version to use) is now a functional attribute of the watch itself. There are two main parts not yet fully merged: - changing the version in sotw when using stable versions. The requirement to prepend cache version prefix makes it harder to abstract - defining whether a change only removing resources should trigger a response. This could be made a functional flag but given its intersection with `fullStateResponses` seemed fragile Signed-off-by: Valerian Roche <valerian.roche@datadoghq.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Following the addition of stable version support in sotw, the remaining differences of behavior between sotw and delta are:
In this context, the code can now be mostly merged, apart from the type differences on requests and responses (which I think can be reduced to none soon, but requires more rework on simple side and would be somewhat backward incompatible).
In this PR, the linear cache no longer treats sotw and delta watches differently. They are tracked in the same maps and the changes and responses are computed in a common method. Differences in behavior (e.g. full state or which version to use) is now a functional attribute of the watch itself.
There are two main parts not yet fully merged:
fullStateResponsesseemed fragile