Skip to content

Conversation

alexander-yevsyukov
Copy link
Contributor

@alexander-yevsyukov alexander-yevsyukov commented Mar 6, 2017

This PR:

  • Removes markArchived() and markDeleted() methods in repositories and storages.
  • Renames Visibility proto type into LifecycleFlags.
  • Introduces EntityWithLifecycle interface.
  • Introduces StorageWithLifecycleFlags interface.
  • Renames VisibilityField into LifecycleFlagField.

@alexander-yevsyukov alexander-yevsyukov self-assigned this Mar 6, 2017
@codecov
Copy link

codecov bot commented Mar 6, 2017

Codecov Report

Merging #372 into master will increase coverage by 0.02%.
The diff coverage is 94.49%.

@@             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.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3d283d4...24ce525. Read the comment docs.

@alexander-yevsyukov
Copy link
Contributor Author

@armiol, PTAL.

Copy link
Contributor

@armiol armiol left a 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.
Copy link
Contributor

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Identifiers?

Copy link
Contributor Author

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();
Copy link
Contributor

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.
Copy link
Contributor

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.
Copy link
Contributor

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.

Copy link
Contributor Author

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.

@alexander-yevsyukov
Copy link
Contributor Author

@armiol, PTAL.

@alexander-yevsyukov alexander-yevsyukov changed the title Visibility on entity level Lifecycle flags for entities Mar 7, 2017
@alexander-yevsyukov
Copy link
Contributor Author

@armiol, PTAL. Specific repository views will be in an separate PR.

The converter's output is only `null` if the input is `null`. Since the passed entity isn't null, the check is redundant.
Copy link
Contributor

@armiol armiol left a 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.
Copy link
Contributor

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) {
Copy link
Contributor

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 {
Copy link
Contributor

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.

Copy link
Contributor Author

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.

@alexander-yevsyukov
Copy link
Contributor Author

@armiol, PTAL.

@armiol
Copy link
Contributor

armiol commented Mar 9, 2017

@alexander-yevsyukov as discussed vocally, the storage mechanism will be updated and refactored.
So LGTM for now.

@alexander-yevsyukov alexander-yevsyukov merged commit 4d3b1fe into master Mar 9, 2017
@alexander-yevsyukov alexander-yevsyukov deleted the visibility-on-entity-level branch March 9, 2017 15:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants