-
Notifications
You must be signed in to change notification settings - Fork 12
Lifecycle flags for entities #372
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
It's already available on the level of the package.
Also removed `markArchived()` and `markDeleted()` methods (which duplicate `writeVisibility()` methods).
Codecov Report
@@ Coverage Diff @@
## master #372 +/- ##
============================================
+ Coverage 93.18% 93.21% +0.02%
+ Complexity 2327 2314 -13
============================================
Files 232 231 -1
Lines 7615 7589 -26
Branches 559 561 +2
============================================
- Hits 7096 7074 -22
Misses 390 390
+ Partials 129 125 -4 Continue to review full report at Codecov.
|
@armiol, PTAL. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alexander-yevsyukov please see my comments.
Let's discuss the VisibleEntity#visibilityChanged()
.
|
||
/** | ||
* Routines common for all mismatches. | ||
* An entity which has visibility. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we reference some definition of visibility
? Or something that would allow readers to catch up on the subject.
.build(); | ||
write(id, updated); | ||
} else { | ||
// The AggregateStateId is a special case, which is not handled by the Identifier class. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Identifiers
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code that creates the string form of an ID is actually in the Identifier.Type
enum.
The AggregateStateId
being a plain Java class (not one of primitive wrappers that we support, and not a Message
) doesn't fall into the case
in Identifier.toString()
, which causes the error.
I didn't want to extend the Identifier
for this particular case, hence the comment.
/** | ||
* Verifies whether visibility of the entity changed since its initialization. | ||
*/ | ||
boolean visibilityChanged(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's an odd interface method. Seems more like a utility method of an abstract class
-level.
checkArgument(!expected.equals(actual), ERR_CANNOT_BE_EQUAL); | ||
} | ||
/** | ||
* Verifies whether visibility of the entity changed since its initialization. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should probably be Tells whether ...
, since if fact there is verification done per se, i.e. no exceptions thrown.
* | ||
* <p>This method returns {@code Optional.absent()} if none of the | ||
* flags of visibility flags were set before. This means that | ||
* the entity is visible to the regular queries. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While it is perfectly clear to me, the regular queries
may cause some questions. What are they? Are there irregular queries? Do the irregular queries act differently in the past? Etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll remove the last sentence. It repeats what is already said in Visibility
.
@armiol, PTAL. |
@armiol, PTAL. Specific repository views will be in an separate PR. |
Tested `Preconditions` for null tolerance
The converter's output is only `null` if the input is `null`. Since the passed entity isn't null, the check is redundant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alexander-yevsyukov LGTM except for a few minor comments and one logical duplicate, that seems worth discussing. Please see my comments.
|
||
/** | ||
* Routines common for all mismatches. | ||
* A storage that allows to update lifecycle flags of entities. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's reference the LifecycleFlags
via {@link...}
here as well.
final Map<AggregateStateId, EntityRecord> resultMap = Maps.filterKeys( | ||
allRecords, | ||
new Predicate<AggregateStateId>() { | ||
@Override | ||
public boolean apply(@Nullable AggregateStateId stateId) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks unformatted. Maybe, just a GitHub bug.
// | ||
message Visibility { | ||
// The lifecycle flags of an entity. | ||
message LifecycleFlags { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a pity we have to duplicate LifecycleFlags
proto message and LifecycleFlagField
class structure.
Can we avoid it somehow? ATM, we'll have to append the same changes to these two classes if any new flags are introduced.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would require having a general mechanism of transforming a message into a set of storage fields. And detecting simple cases like just boolean
flags like this. Kinda Hibernate :) I'd say, it should be a separate PR anyway.
@armiol, PTAL. |
Get rid of `Tuple`
@alexander-yevsyukov as discussed vocally, the storage mechanism will be updated and refactored. |
This PR:
markArchived()
andmarkDeleted()
methods in repositories and storages.Visibility
proto type intoLifecycleFlags
.EntityWithLifecycle
interface.StorageWithLifecycleFlags
interface.VisibilityField
intoLifecycleFlagField
.