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

[question] can only be used with a log that provides a directory #13

Open
nichoth opened this issue Nov 20, 2018 · 3 comments
Open

[question] can only be used with a log that provides a directory #13

nichoth opened this issue Nov 20, 2018 · 3 comments

Comments

@nichoth
Copy link

nichoth commented Nov 20, 2018

I was wondering if anyone could explain this restriction, where the flumelog must have a local directory. It seems like the dir name is only used to create the location for the leveldb, but is there another reason for this design?

  function create() {
      closed = false
      if(!log.filename)
        throw new Error('flumeview-level can only be used with a log that provides a directory')
      return Level(path.join(dir, name), {keyEncoding: charwise, valueEncoding: 'json'})
    }

https:/flumedb/flumeview-level/blob/master/index.js#L27

@dominictarr
Copy link
Contributor

normally, you have a flumelog which is a file, and then a bunch of flumeviews, which also probably have files. To avoid a configuration nightmare, the views just created files or directories based on their name, next to the log. flumelog-memory doesn't have a log, it just creates a temporary log in memory. some other views (such as flumeview-reduce) notice this, and when used with a memory log, provide a memory view, but flumeview-level doesn't have an easy way to do this, so it throws an error instead, because it doesn't know where to put the file.

really the memory log thing is just for testing, but to make sure that it really really works, I usually test with a real log anyway.

@christianbundy
Copy link
Member

Would it be appropriate to default to require('os').tmpdir() instead of throwing an error?

@dominictarr
Copy link
Contributor

@christianbundy yes that would work. sometimes maybe print something in that case though because accidentially passing a memory log when you ment not to could be a mistake

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 a pull request may close this issue.

3 participants