-
Notifications
You must be signed in to change notification settings - Fork 49
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
[dbsync] Fix open issues in rsync library and make it functional #782
base: main
Are you sure you want to change the base?
[dbsync] Fix open issues in rsync library and make it functional #782
Conversation
156aeb9
to
d39671f
Compare
try { | ||
instruction.writeDelimitedTo(instructionStream); | ||
} catch (IOException e) { | ||
throw new RuntimeException("Failed to write instructions", e); |
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.
Will still delete the intermediate files like checksum or instructions if it throws here?
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 was thinking whats best way to handle this because failure can happen at different stages and may be some of the files we are deleting are not even created.
One option is we do cleanup on best effort in a finally block at top level that encompasses all exceptions. But ignore any error while trying to delete including file not found errors.
} | ||
|
||
// Reconstruct on GCS | ||
server.reconstruct(); | ||
|
||
//TODO delete the jobs from cloudrun | ||
server.deleteJob(Mode.GENERATE); |
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.
Is the goal to have these running as servers instead of as a one time command line program later?
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.
To my knowledge we wanted to run it as jobs running on demand, since frequency of execution might actually be less.
Though i was checking if there was a way to re-use deployed jobs and run with different inputs instead of deploying new jobs for each file. But for now couldn't find good solution for this.
project, location, Mode.GENERATE, | ||
String.format("%s && %s", jarDownloadCommand, generateCommand) | ||
); | ||
project, |
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'd suggest separating these formatting changes next time. It makes it harder to see what are real changes and what are just style changes.
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.
Yes will keep in mind. I initially had setup "format on save" and didn't realize would end up with big diff
// If target files path is gs://target_bucket/dir/target/file.txt | ||
// Staging bucket is gs://target_bucket/ | ||
// Then staging files will be stored as gs://target_bucket/dir/target/file.txt/staged | ||
String targetRelativePath = UriUtil.getRelativePath(targetUri); |
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.
This variable is used only once a line below, you can inline it
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.
Yes will update
// TODO: Switch to simple write to save storage and read by byte size | ||
checksum.writeDelimitedTo(checksumStream); | ||
} catch (IOException e) { | ||
throw new RuntimeException("Failed to generate checksum", e); |
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 won't delete the staging files in this case?
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.
Similar to other comment #782 (comment)
Need a good way cleanup regardless of the error
@@ -55,4 +63,14 @@ public ByteSource getInstructionsByteSource() { | |||
public ByteSink getInstructionsByteSink() { | |||
return storage.newByteSink(instructionUri); | |||
} | |||
|
|||
@Override | |||
public void moveStagedFileToTarget(boolean deleteStagingFiles) { |
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 think it's better to have a deleteStagedFiles method instead of passing in boolean flag here.
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.
Ya make sense. Will update
This PR fixes all the open issues to get the library functional
Issues being fixed
Other changes
Testing:
test manually with following params
Screenshot of staging bucket files

Screenshot of target file

Note: Need to setup proper integ/e2e tests but for now trying to get it working and unblock dependent work