Hacker News Reader

Comment by _cereal | Hacker News Reader

Nice, but how it deals with multiple concurrent writes? I see you are using transactions but, as far as I know, sqlite3 supports database-level locking, so one writing instance, unless using ATTACH and separating tables into multiple files, to enable a sort of table-level locking.

Are you considering to add support to other databases?

View on HN

>but how it deals with multiple concurrent writes?

I'm afraid I'm not very familiar with how go-sqlite3 handles that. I just started learning golang a month ago, so it's all quite new to me.

Maybe someone else will have a better answer.

>Are you considering to add support to other databases?

At the moment, no. Comments aren't exactly big data ;)

Just curious - which databases would you like to see and why (what do they offer over sqlite)?

Single insert per transaction is slow with sqlite, but slow is sort of relative. It would be probably be 10 to 80 inserts per second or so, a little faster if you turn off synchronous writes in sqlite.

I would guess most use cases for this relatively simple comment software wouldn't be expecting that many comments anyway.

An agnostic data layer should probably go on your list, but I imagine other stuff would be higher on the list...like a captcha. Spam will likely be the top issue long before performance.

I'd say put in an ODBC driver. It gets you support for a lot of databases right out the gate, especially if you keep things to a relatively simple subset. That way, someone already running a postgresql or mysql database can plug things in and not need to track another place data is stored.

Reply on news.ycombinator.com