Skip to content
This repository has been archived by the owner on Oct 16, 2018. It is now read-only.

Re-work segment.Fields/Terms to use iterators #79

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

prateek
Copy link
Collaborator

@prateek prateek commented May 17, 2018

Fixes #66

@@ -209,24 +206,29 @@ func (r *fsSegment) Close() error {
return errReaderClosed
}
r.closed = true
// ensure all references that depenend on this segment are released
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: sp of "depend"

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

thanks for the catch. fixed.

@codecov
Copy link

codecov bot commented May 17, 2018

Codecov Report

Merging #79 into master will decrease coverage by 0.36%.
The diff coverage is 71.42%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master      #79      +/-   ##
==========================================
- Coverage   72.54%   72.18%   -0.37%     
==========================================
  Files          54       57       +3     
  Lines        2284     2398     +114     
==========================================
+ Hits         1657     1731      +74     
- Misses        411      442      +31     
- Partials      216      225       +9
Impacted Files Coverage Δ
index/segment/mem/segment.go 76.27% <100%> (ø) ⬆️
persist/reader.go 79.06% <100%> (ø) ⬆️
index/segment/mem/concurrent_postings_map.go 92.15% <100%> (ø) ⬆️
index/segment/mem/terms_dict.go 89.7% <100%> (ø) ⬆️
index/segment/fs/writer.go 63.3% <33.33%> (-6.55%) ⬇️
index/segment/fs/options.go 42.85% <42.85%> (ø)
index/segment/mem/options.go 47.61% <75%> (+7.61%) ⬆️
index/segment/fs/fst_terms_iterator.go 85% <85%> (ø)
index/segment/fs/segment.go 57.98% <91.66%> (+0.98%) ⬆️
index/segment/mem/bytes_slice_iterator.go 92.59% <92.59%> (ø)
... and 3 more

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 d5d44ea...84ae9c9. Read the comment docs.

Copy link
Contributor

@jeromefroe jeromefroe left a comment

Choose a reason for hiding this comment

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

Will it be hard to rebase the other FST diff onto this one? Just curious if it would make sense to hold off for that one.

type fstTermsIter struct {
iterOpts newFstTermsIterOpts

initialized bool
Copy link
Contributor

Choose a reason for hiding this comment

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

not sure if it's worth it but I think you can resolve the maligned lint by moving initialized above done:

iter        *vellum.FSTIterator
err         error
initialized bool
done        bool

return f.err
}

func (f *fstTermsIter) Close() error {
Copy link
Contributor

Choose a reason for hiding this comment

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

need to set f.done to true here in case someone calls close before reaching the end of the iterator?

}

if err != nil {
f.done = true
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: maybe only set f.done to true if the error was a vellum.ErrIteratorDone in case we ever want to distinguish the two case in the future?

"github.com/couchbase/vellum"
)

type newFstTermsIterOpts struct {
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: it seems strange to me to call these options since they're actually required parameters and we need to call close on them, maybe it would be worth just passing them directly in the constructor?

var _ sgmt.OrderedBytesSliceIterator = &fstTermsIter{}

func (f *fstTermsIter) Next() bool {
if f.done || f.err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

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

do we need to check if the context has been closed here?

@@ -209,24 +206,29 @@ func (r *fsSegment) Close() error {
return errReaderClosed
}
r.closed = true
// ensure all references that depened on this segment are released
r.ctx.BlockingClose()
Copy link
Contributor

Choose a reason for hiding this comment

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

side thought: should we integrate this context into the mem segment as well? but if we do, aren't we back to ref-counting?

b.done = true
return false
}
b.current = b.backingSlice[b.currentIdx]
Copy link
Contributor

Choose a reason for hiding this comment

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

Since we're reusing the underlying byte slice should we call out in the interface definition that the byte slice returned from Current is only valid until the subsequent call to Next?

// Next returns a bool indicating if there are any more elements
Next() bool

// Current returns the current element.
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we call that the element is only valid until the subsequent call to Next?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants