[
https://issues.apache.org/jira/browse/BEAM-5910?focusedWorklogId=186431&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-186431
]
ASF GitHub Bot logged work on BEAM-5910:
----------------------------------------
Author: ASF GitHub Bot
Created on: 17/Jan/19 17:13
Start Date: 17/Jan/19 17:13
Worklog Time Spent: 10m
Work Description: jklukas commented on pull request #6914: [BEAM-5910]
Add lastModified field to MatchResult.Metadata
URL: https://github.com/apache/beam/pull/6914#discussion_r248762310
##########
File path:
sdks/java/core/src/main/java/org/apache/beam/sdk/io/fs/MetadataCoder.java
##########
@@ -46,14 +54,18 @@ public void encode(Metadata value, OutputStream os) throws
IOException {
@Override
public Metadata decode(InputStream is) throws IOException {
+ return decodeBuilder(is).build();
+ }
+
+ Metadata.Builder decodeBuilder(InputStream is) throws IOException {
ResourceId resourceId = RESOURCE_ID_CODER.decode(is);
boolean isReadSeekEfficient = INT_CODER.decode(is) == 1;
long sizeBytes = LONG_CODER.decode(is);
return Metadata.builder()
.setResourceId(resourceId)
.setIsReadSeekEfficient(isReadSeekEfficient)
.setSizeBytes(sizeBytes)
- .build();
+ .setLastModifiedMillis(UNKNOWN_LAST_MODIFIED_MILLIS);
Review comment:
> What if we let zero as a default. In that case we won't need that and we
will still be ok with AutoValue
To be clear, `0` is only used as a default for `File.lastModified` as used
in `LocalFileSystem`. Other filesystems do not have this same concept of 0 as
default. So any way we go, we will have to explicitly set some default value
for the field.
I agree with you that it's better to set the default within `Metadata`
rather than only in the coder, so I will make that change. And will also change
the default to be 0 to be consistent with `File.lastModified` behavior.
> Also in the current case if you put this only in decode then encode won't
put the right value
Exactly. `encode` _does not_ encode the lastModifiedMillis value; it's
thrown away. And decode provides a default. So encode and decode remain matched
in the number and types of encoded values, and these are compatible with
previous beam versions.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 186431)
Time Spent: 4h (was: 3h 50m)
> FileSystems should retrieve lastModified time
> ---------------------------------------------
>
> Key: BEAM-5910
> URL: https://issues.apache.org/jira/browse/BEAM-5910
> Project: Beam
> Issue Type: Improvement
> Components: sdk-java-core
> Reporter: Jeff Klukas
> Assignee: Jeff Klukas
> Priority: Minor
> Time Spent: 4h
> Remaining Estimate: 0h
>
> In the Java SDK, the Filesystems.match facilities are aimed at listing file
> names and collect very limited additional metadata from the filesystem
> (sizeBytes and isReadSeekEfficient). I propose adding a new field for
> lastModified time to MatchResult.Metadata that each FileSystem would populate
> when listing files.
> This would be a basis for a future improvement to
> FileIO.match(...).continuously(...) where we could let the user opt to poll
> not just for new file names, but also for existing file names if their
> content has been updated.
> In the near term, the addition of lastModified to Metadata would allow users
> to implement their own polling logic on top of Filesystems.match to detect
> and download new files from any of the supported filesystems.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
