CLI tool

[fergiemcdowall]

Twould be nice to be able to query an index on the command line

[eklem]

Somebody made something like this already. We can check if it's something we can fork.

[eklem]

https://www.npmjs.com/package/sosays

[eklem]

Would be cool if we could just expose the full API. Even if the input will be a little technical it will make the learning process a lot easier. I'll have a go later and document if any success.

[eklem]

I'm guessing we can just do an input to a function, and we don't need any .then-chaining, other than a console.log(result) from each function.

Will try with minimist for parsing arguments and use a case switch for the different API commands, doing something like si PUT [{obj1},{obj2}]

[fergiemcdowall]

Yes, it would be nice to find some way to make a standalone binary that can play nice with other unix commandline programs using pipes and redirects.

[eklem]

Also, browser console works quite well, even if a bit different in Firefox and Chrome.

[fergiemcdowall]

Oh- cool! :)

[eklem]

Firefox is working good, Chrome, just partly (.then() won't work). Good learning tool, I'll blog about it.

[eklem]

So, if I did this, would JSON stringified result be a good output? And parse input when search-index is piped to? Then you could do

si --AND <query> | si --DOCUMENTS

and get actual results out.

[eklem]

@fergiemcdowall, should I make it a separate module? Then search-index is kept with few dependencies. Or is it important enough to keep it in?

[eklem]

Here's how to get data in through a pipe to search-index.

[fergiemcdowall]

search-index queries are now essentially small js programs made up of promises. If it is possible just to send in a query as a "lump of javascript" then that would be the best. If possible?

[eklem]

Yes, that's a good idea. I was more thinking in the map reduce way:

some query | another query on returned ID's | yet another | DOCUMENTS

But I think your approach is better though, it's a good mix of helping people get familiar with the query syntax and being easy. I can just use eval() or something. Will still try to keep the piping from one query to another. And do some shorthand on defining db (and name). Then you can do cool things like put a lot of data into one search-index, do a query or string of queries and put the result into another search-index.

[fergiemcdowall]

I do wonder if it would be a good idea to come up with a JSON representation of the query language though. That way it could be passed around more easily. Especially over HTTP

[eklem]

If we, for now, look at the JS-code way, I think something like .then(result) or .then(resultPrint)`should actually work, result/resultPrint being a function that do JSON.stringify and then console.log.

[eklem]

I'll have a go at this again when the jsonAPI gets stable enough =)

[eklem]

@fergiemcdowall, this means some extra dependencies. Is that okay, or should we make a separate one?

[fergiemcdowall]

One the JSON API is finished, it should be pretty easy to make a CLI app using process.stdin and process.stdout. Then you could do stuff like

# pipe data in
cat dataFile | searchIndex

# read data
searchIndex -r "{ SEARCH: [ 'search', 'terms' ] }"