Also the name of a very popular R package. Maybe call it JSONdb? Or JSONstore?
Show HN: JSONlite – A simple, serverless, zero-configuration JSON document store
61–66 of 66 posts
Re: Show HN: JSONlite – A simple, serverless, zero-configuration JSON document store
#62Earlier quoted context omitted.
Outputting 1m lines to the console is likely to be slow - and isn't really ls' fault?
For troubleshooting or statistical reasons. It's serving as the backing data store. So piping through grep, or to wc, etc. Specifically not sending the output to the screen.
Sure.
As this is a standard Ubuntu install, ls is indeed aliased to "ls --color" - but afaik ls as standard detects pipes, and turns off color (so you don't get a lot of control characters if you do "ls --color | sort > file.txt". Unless you use --color=always if I recall correctly.
Just wanted to differentiate between "select * from documents" and "select count(*) from documents" being slow.
Re: Show HN: JSONlite – A simple, serverless, zero-configuration JSON document store
#63I think your title might not be the best; * Serverless typically implies something accessible from more than the host you're on * It's not zero configuration, there's at least 1 configurable parameter (albeit with a sensible default) * I'm actually not even clear why this is a document store limited to JSON, other than you're piping it though a JSON python module. Having done some things like this in the past, as you…
I agree that "serverless" now mainly means "Function as a Service." The goal here is convey that there is no server component of the database, similar to SQLite and unlike PostgreSQL. What is the correct terminology to highlight this architectural distinction?
"embeddable datastore" is the right term
Re: Show HN: JSONlite – A simple, serverless, zero-configuration JSON document store
#64If you are going to invoke the sacred name of 'sqlite', then I expect to see rock-solid code and quality testing. Instead, there are two tiny tests, and I found a couple of issues in 30 seconds of looking at the code. EDIT: I should prove my point. 1) Race condition on calculating uuid (obviously won't be too serious for a good uuid implementation) 2) No check that file is written successfully. 3) No check when json…
Heads up, just fixed the bug where providing invalid json to set would write an empty file with a uuid filename to the data directory. Now providing invalid json to set errors with no file written to the data directory. New version is 1.1.0 ( https://github.com/nodesocket/jsonlite/releases/tag/1.1.0 ) if you care.
Just wanted to say, glad to see these are being fixed. My initial message was a little harsh -- although github makes it hard to tell if you are making a new library for fun, or something you really want people using for important customer data!
Re: Show HN: JSONlite – A simple, serverless, zero-configuration JSON document store
#65I think your title might not be the best; * Serverless typically implies something accessible from more than the host you're on * It's not zero configuration, there's at least 1 configurable parameter (albeit with a sensible default) * I'm actually not even clear why this is a document store limited to JSON, other than you're piping it though a JSON python module. Having done some things like this in the past, as you…
I agree that "serverless" now mainly means "Function as a Service." The goal here is convey that there is no server component of the database, similar to SQLite and unlike PostgreSQL. What is the correct terminology to highlight this architectural distinction?
your headline is good except the term "serverless".
please drop it.
The term means much more than "not hosting it on a server". As somebody pointed out, "embedded datastore" may be a better term.
Re: Show HN: JSONlite – A simple, serverless, zero-configuration JSON document store
#66Earlier quoted context omitted.
I agree that "serverless" now mainly means "Function as a Service." The goal here is convey that there is no server component of the database, similar to SQLite and unlike PostgreSQL. What is the correct terminology to highlight this architectural distinction?
your headline is good except the term "serverless". please drop it. The term means much more than "not hosting it on a server". As somebody pointed out, "embedded datastore" may be a better term.
I agree the term is confusing now that "serverless" has a cloud-related definition, but in the database world, it is traditionally one of the terms used as an antonym to "client/server database". See, for example: https://sqlite.org/serverless.html