Skip to content
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

Fix imports of multiple databases in one export file #9352

Merged
merged 1 commit into from
Feb 5, 2018
Merged

Fix imports of multiple databases in one export file #9352

merged 1 commit into from
Feb 5, 2018

Conversation

wwilfinger
Copy link
Contributor

Fixes #9336

I'm not happy with some of the names here. I also want to add a test that hits the 5000 batchSize to verify everything works there. Will probably look at cmd/influx_inspect/export/export_test.go to see how to generate larger test dbs.

batchWrite was using the last database and retention policy read from
the input file. Because batchWrite was called only every batchSize lines
or at EOF, databases with fewer than batchWrite points could be imported
into the incorrect database.

This change forces a flush with batchWrite whenever processDML reads a
change in database or retention policy.

Required for all non-trivial PRs
  • Rebased/mergable
  • Tests pass
  • CHANGELOG.md updated
  • Sign CLA (if not already signed)

@ghost ghost added the proposed label Jan 22, 2018
@@ -178,10 +181,18 @@ func (i *Importer) processDML(scanner *bufio.Reader) error {
return nil
}
if strings.HasPrefix(line, "# CONTEXT-DATABASE:") {
i.database = strings.TrimSpace(strings.Split(line, ":")[1])
i.dmlDatabase = strings.TrimSpace(strings.Split(line, ":")[1])
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a reason why you don't just call i.batchWrite() here before changing the database? It seems like there would be less of a code change if the batch were just flushed whenever the context database or retention policy is changed. It looks like batchWrite() is pretty safe to call multiple times. The only caveat is that, for some reason, this section of code:

i.batch = i.batch[:0]

This is in batchAccumulator rather than inside of batchWrite. If you move that piece of code to the end of batchWrite and remove it from batchAccumulator, you can just call batchWrite whenever you want to flush the writes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You're right, thanks. That was much easier. I rebased and pushed.

Not sure how to write a test with more than 5000 points without pasting in a gigantic string of json. Open to suggestions.

@rbetts rbetts requested a review from aanthony1243 February 5, 2018 16:55
Copy link
Contributor

@aanthony1243 aanthony1243 left a comment

Choose a reason for hiding this comment

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

straightforward change, tests look good.

batchWrite was using the last database and retention policy read from
the input file. Because batchWrite was called only every batchSize lines
or at EOF, databases with fewer than batchWrite points could be imported
into the incorrect database.

This change forces a flush with batchWrite whenever processDML reads a
change in database or retention policy.
@ghost ghost assigned jsternberg Feb 5, 2018
@ghost ghost added review and removed proposed labels Feb 5, 2018
@jsternberg
Copy link
Contributor

I resolved the changelog conflict and pushed an update. As soon as it passes tests, I'm going to merge this.

Thanks for the help! We should have this change included in the 1.5 release.

@jsternberg jsternberg merged commit 9aeae7c into influxdata:master Feb 5, 2018
@ghost ghost removed the review label Feb 5, 2018
@jsternberg
Copy link
Contributor

Hi @wwilfinger, can you sign the link to the CLA that's here? Thanks.

@jsternberg
Copy link
Contributor

@wwilfinger ping. Can you sign the CLA otherwise we're going to have to revert this change and redo it.

Thanks.

@wwilfinger
Copy link
Contributor Author

wwilfinger commented Feb 9, 2018

@jsternberg My employer's legal team is taking a while to get back to me if I can sign the CLA. Go ahead and revert. I apologize for the waste of time.

jsternberg added a commit that referenced this pull request Feb 9, 2018
…t-export-import"

This reverts commit 9aeae7c, reversing
changes made to 35b44cc.

The contributor was unable to sign the contributor license agreement so
we have to revert this commit.
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.

3 participants