Skip to content
This repository was archived by the owner on Jan 28, 2021. It is now read-only.

Pilosa index driver as library #308

Merged
merged 6 commits into from
Aug 2, 2018
Merged

Pilosa index driver as library #308

merged 6 commits into from
Aug 2, 2018

Conversation

kuba--
Copy link
Contributor

@kuba-- kuba-- commented Jul 31, 2018

Signed-off-by: kuba-- [email protected]

New implementation of index driver (pilosalib). This one also uses pilosa but as a embedded library (comparing to external http server used by pilosa driver)

It closes
#302

@kuba-- kuba-- added enhancement New feature or request proposal proposal for new additions or changes labels Jul 31, 2018
@kuba-- kuba-- requested a review from a team July 31, 2018 14:13
@kuba--
Copy link
Contributor Author

kuba-- commented Jul 31, 2018

Build fails because of:

../../../github.com/pilosa/pilosa/cluster.go:1544:18: multiple-value uuid.NewV4() in single-value context
../../../github.com/pilosa/pilosa/holder.go:529:22: multiple-value uuid.NewV4() in single-value context

We have to start vendoring dependencies also for libraries!

@erizocosmico
Copy link
Contributor

We have to start vendoring dependencies also for libraries!

Yup. But in this case, we should just upgrade to whatever's the latest version of uuid.

@kuba--
Copy link
Contributor Author

kuba-- commented Jul 31, 2018

Build fixed.

cancel()
return nil, nil, err
}
id := uuid.NewV4()
Copy link
Contributor Author

Choose a reason for hiding this comment

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

it complaint because the newest version doesn't return an error

.travis.yml Outdated
- go get -u github.com/pilosa/go-pilosa
- cd "$GOPATH/src/github.com/pilosa/go-pilosa" && git checkout v0.9.0 && cd "$TRAVIS_BUILD_DIR"
- go get -u github.com/golang/dep/cmd/dep
- cd "$TRAVIS_BUILD_DIR"
Copy link
Contributor

Choose a reason for hiding this comment

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

i think we no longer need this

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 mean cd "$TRAVIS_BUILD_DIR"? So far I left it just in case.

Copy link
Contributor

Choose a reason for hiding this comment

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

yep. it was because it used to CD into go-pilosa's dir. Now we don't need that anymore

.travis.yml Outdated
- cd "$GOPATH/src/github.com/pilosa/go-pilosa" && git checkout v0.9.0 && cd "$TRAVIS_BUILD_DIR"
- go get -u github.com/golang/dep/cmd/dep
- cd "$TRAVIS_BUILD_DIR"
- touch Gopkg.toml
Copy link
Contributor

Choose a reason for hiding this comment

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

we could just dep init

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I tried dep init but the problem is that it creates Gopkg files and locks the revision. After that any dep ensure -add or dep ensure -update doesn't work when I try to upgrade to the master (because lock is already set).
And for pilosa/pilosa we need to use master (waiting for 1.0.2).

.travis.yml Outdated
- go get -u github.com/golang/dep/cmd/dep
- cd "$TRAVIS_BUILD_DIR"
- touch Gopkg.toml
- dep ensure -v -add "github.com/pilosa/[email protected]" "github.com/pilosa/pilosa@master"
Copy link
Contributor

Choose a reason for hiding this comment

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

maybe we could set the specific revision of pilosa instead, so we're in control if something changes

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yup, they promised to release 1.0.2 y'day, but nothing happened, so I pulled master.
The plan is maybe to use dep init and set up certain version (1.0.2+, because current 1.0.1 doesn't work for us).

Copy link
Contributor

Choose a reason for hiding this comment

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

We can still pin a revision, even if it's not a release, right? I mean pinning it to the hash of current master

Signed-off-by: kuba-- <[email protected]>
@kuba--
Copy link
Contributor Author

kuba-- commented Aug 1, 2018

Removed TRAVIS_BUILD_DIR. Either we plan to review and merge (what works with pilosa@master) or wait for [email protected] which in theory should be released on Tuesday (y'day) ;)

})
log.Warn("could not read index file, index is corrupt and will be deleted")

if err := os.RemoveAll(path); err != nil {
log.Warn("unable to remove folder of corrupted index")
if err := os.RemoveAll(configfile); 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.

I would prefer to delete the path instead of each file separately. Why we change it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The problem here is folder's structure. We don't have id subfolder anymore. Just all db/table indexes go to the one pilosa index folder.
I wanted to keep the id folder for resources like config, mapping, etc. but it will distract pilosa/pilosa, because when you load an index in pilosa it goes through subfolders (and don't validate it), so at the end it creates fake/invalid extra indexes. That's why I flatten the structure and left subfolders to pilosa internals.

But right now I thought about another folders refactoring.
How about:

root
|-db
   |-table
      |-[driver id] # pilosa folder if needed
      |-[id 1] # index metadata (config, mapping, ...)
      |-[id 2]
...

The pros. here is the structure is almost what we had before, so deleting the index is easier - you can just delete a id folder.
The cons. yo don't have connection between id and driver. If you have multiple indexes on the same table from different drivers you don't know which index belongs to which driver. What in theory may not be problem if we mark it in a config file.
WDYT?

}

// Delete the index with the given path.
func (d *Driver) Delete(idx sql.Index) error {
path := filepath.Join(d.root, idx.Database(), idx.Table(), idx.ID())
if err := os.RemoveAll(path); err != nil {
if err := os.RemoveAll(d.configFileName(idx.Database(), idx.Table(), idx.ID())); 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.

The same as the previous comment.

@@ -44,7 +44,7 @@ func TestID(t *testing.T) {
func TestLoadAll(t *testing.T) {
require := require.New(t)

path, err := ioutil.TempDir(os.TempDir(), "indexes")
path, err := ioutil.TempDir(os.TempDir(), "indexes-")
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 set a path called go-mysql-server on temp dir to be able to delete it at the end of every test?

Copy link
Contributor

Choose a reason for hiding this comment

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

The name is irrelevant to delete them at the end of every test. You just have to os.RemoveAll(PathReturnedByTempDir)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah, we should at least make it consistent across all tests.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added setup, cleanup functions for tests' tmp dirs.

@@ -94,7 +94,7 @@ func TestSaveAndLoad(t *testing.T) {

db, table, id := "db_name", "table_name", "index_id"
expressions := makeExpressions("lang", "hash")
path, err := ioutil.TempDir(os.TempDir(), "indexes")
path, err := ioutil.TempDir("", "indexes")
Copy link
Contributor

Choose a reason for hiding this comment

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

the same as the previous comment.

@kuba--
Copy link
Contributor Author

kuba-- commented Aug 1, 2018

I've locked pilosa to the commit hash: edf6fa9c67caeab6019fb17ab82425a74fdfaf87

Signed-off-by: kuba-- <[email protected]>
@kuba--
Copy link
Contributor Author

kuba-- commented Aug 1, 2018

I have a feeling that following folder structure will be better for us (and more backward compatible) - WDYT?

root/
└── db
    └── table
        ├── .pilosa #pilosa special folder
        │   └── idx-d9b85cddd6ac716f0326c32c7ba4bd9ae2aeb558
        │       └── fld-daef88b79b2d1e52c779c70d4aa814546a1b10c2
        │           └── views
        │               ├── fragments
        │               │   ├── 0
        │               │   └── 0.cache
        │               └── standard
        ├── idx_1 #index id_1 metadata folder
        │   ├── .processing
        │   ├── config.yml
        │   └── mapping.db
        └── idx_2 #index id_2 metadata folder
            ├── config.yml
            └── mapping.db

@ajnavarro
Copy link
Contributor

@kuba-- can you rebase please? (I merged first the ExpressionHash change than this one, sorry... :S)

@ajnavarro
Copy link
Contributor

@kuba-- LGTM the proposed folder structure.

@ajnavarro
Copy link
Contributor

Also, can you check the documentation to check some inconsistences? thanks!

@kuba--
Copy link
Contributor Author

kuba-- commented Aug 1, 2018

I'm in the middle of resolving conflicts. After that I'll refactor folders structure and check docs.
A good thing about a new structure is backward compatibility, so I hope nothing has to be changed in docs (apart from adding a new driver which won't require pilosa server)

@kuba-- kuba-- added the wip work in progress label Aug 1, 2018
kuba-- added 2 commits August 1, 2018 21:17
@kuba-- kuba-- removed the wip work in progress label Aug 2, 2018
@kuba--
Copy link
Contributor Author

kuba-- commented Aug 2, 2018

@ajnavarro - ready to merge.

@ajnavarro ajnavarro merged commit f813628 into src-d:master Aug 2, 2018
@kuba-- kuba-- deleted the pilosa-lib branch August 2, 2018 09:15
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request proposal proposal for new additions or changes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants