UpdateTargetLocator->ActionTargetLocator, refactor part 2 #262
Conversation
There was a problem hiding this comment.
@tatu-at-datastax Can you see if we can move the 2 class to util package. Also there is a unit test failure.
| */ | ||
| public record UpdateTarget( | ||
| public record ActionTarget( |
There was a problem hiding this comment.
Same as what is in UpdateTargetLocator.
| * possibly Projection) | ||
| * </ul> | ||
| */ | ||
| public class ActionTargetLocator { |
There was a problem hiding this comment.
Can we have this class named as just TargetLocator and move it to util package? That way we can use it for projection/sorting.
There was a problem hiding this comment.
@maheshrajamani Yes, I will do that today. Was wondering about it since it's not really update (or update action) specific.
There was a problem hiding this comment.
Are you going to do it as part of this PR?
|
Renamed "UpdateTarget[Locator]" to "PathMatch[Locator]", moved to util. Did other related renaming, hopefully didn't miss too many references. |
What this PR does:
Further refactoring of existing
UpdateTarget[Locator]intoActionTarget[Locator]for more efficient handling, reuse.Specifically now decoding of target locator for
UpdateOperations occurs during construction, and not evaluation: this reduces processing for "updateMany()" use case. Similarly added method (ActionTargetLocator.findValueIn()) is planned to be usable for in-memory Sorting (and later on hopefully with Projection as well).Also pushes handling of
Actions (per-field part of full Update Operation) to base class to allow centralized path-conflict checking (to solve #232 in near future)Which issue(s) this PR fixes:
Fixes #257
Checklist