-
Notifications
You must be signed in to change notification settings - Fork 122
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
Provide a way to get last file revisions #1096
base: main
Are you sure you want to change the base?
Conversation
@@ -408,29 +408,68 @@ private static Revision normalizeRevision(AggregatedHttpResponse res) { | |||
@Override | |||
public CompletableFuture<Map<String, EntryType>> listFiles(String projectName, String repositoryName, | |||
Revision revision, PathPattern pathPattern) { | |||
return listFiles0(projectName, repositoryName, revision, pathPattern, -1, |
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.
Question) What do you think of setting the default value as 1
for both client/server side since it seems like 1 represents "don't search the history"?
Personally, I think it makes more sense that:
- 0 represents "check backwards history for 0 revisions"
- validate on
includeLastFileRevision<0
The current implementation seems fine though.
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.
Good idea.
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.
0 represents "check backwards history for 0 revisions"
If so, should 0 and 1 return the same result?
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.
Personally, I think it makes more sense that:
0 represents "check backwards history for 0 revisions"
validate on includeLastFileRevision<0
I meant it feels more intuitive to me that the parameter represents the number of revisions to go backwards. (i.e. Revision#backward(int)
).
I think the current implementation is fine as long as 1) the default value is well defined with validation 2) and the javadocs are clear. It might be helpful if the parameter name better represents the meaning of "check x number of revision including the head revision" as well.
super(repo); | ||
this.revision = requireNonNull(revision, "revision"); | ||
this.query = requireNonNull(query, "query"); | ||
this.includeLastFileRevision = includeLastFileRevision <= 1 ? -1 : includeLastFileRevision; |
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.
Do we not need to check equality based on includeLastFileRevision
as well?
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 my mistake.
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 great. 👍 Left some suggestions. 😉
|
||
return client.execute(headers(HttpMethod.GET, path.toString())) | ||
.aggregate() | ||
.thenApply(res -> getFiles(normRev, res)); | ||
.thenApply(res -> getFiles(res)); |
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.
.thenApply(res -> getFiles(res)); | |
.thenApply(ArmeriaCentralDogma::getFiles); |
*/ | ||
public Entry<T> withRevision(Revision revision) { | ||
requireNonNull(revision, "revision"); | ||
return new Entry<>(revision, path, type, content, true); |
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.
Probably cache the allowNullContent
and reuse it here for better accuracy?
* @param type the type of the {@link Entry} | ||
* @param <T> the content type. {@link JsonNode} if JSON. {@link String} if text. | ||
*/ | ||
public static <T> Entry<T> ofNullable(Revision revision, String path, EntryType type, @Nullable T content) { |
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.
What do you think of removing the content
from the parameters if you want to make a nullable content entry?
Otherwise, I think we can use the above method which takes a @Nullable T content
.
.filter(entry -> entry.type().type() != Void.class) | ||
// Remove the heading `/` | ||
.map(entry -> entry.path().substring(1)) | ||
.collect(Collectors.toList()); |
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.
Immutable?
final Map<String, Revision> lastRevisionMap = new HashMap<>(); | ||
|
||
// At this point, we are sure: from.major >= to.major and read lock is acquired. | ||
try (ObjectReader reader = jGitRepository.newObjectReader(); |
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.
What do you think of using the caching object reader that is introduced in #1097? 😉
if (revCommit.getParentCount() == 0) { | ||
break; // Reached the root commit | ||
} | ||
|
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.
Probably we can add:
assert revCommit.getParentCount() == 1;
treeWalk.reset(); | ||
treeWalk.addTree(revCommit.getTree()); | ||
treeWalk.addTree(revCommit.getParent(0).getTree()); |
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.
We can do:
treeWalk.reset(); | |
treeWalk.addTree(revCommit.getTree()); | |
treeWalk.addTree(revCommit.getParent(0).getTree()); | |
treeWalk.reset(revCommit.getTree().getId(), revCommit.getParent(0).getTree()); |
* | ||
* |
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.
* | |
* | |
* |
Motivation:
Central Dogma's content API does not return a file revision when the file is modified.
Alternatively, users can use the history API to find the file revision. One downside of the history API is that we couldn't use it to find the last file revisions of multiple files at once, requiring N queries instead.
If the content API can directly return the last file revision, it would eliminate the need to use the history API and execute N queries. Additionally, since the request is simple, caching would be beneficial from the server’s perspective. If multiple servers in the cluster perform the same operation due to a specific event, the cache hit rate is expected to be high.
Modifications:
includeLastFileRevision (int)
as a query parameter tolistFiles
andgetFiles
API. If the value is greater than 1,EntryDto
may include the modified file revision.FilesWithRevisionRequest
is added to fluent specifyincludeLastFileRevision
in the get files or list files API.blockingFindLastFileRevisions()
to search for file revision within a range of revisions. If a file is not found in the revisions,Revision.INIT (1)
is filled instead.Result:
You can now retrieve the last file revisions using the list files API and the get files API.