Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

sqlite can be handy but it's not a substitute for testing against a staging instance of another database platform. It ignores a lot of mistakes in column types and size limits and sometimes even foreign keys. If anything, I would want tests to be more strict than prod.


Your point is correct, but I'm afraid you might not have understood what I meant -- I meant that people should be considering using SQLite in production.

Agreed that testing against copies of production or staging instances that are as close as possible to production is important, but what I'm suggesting is that you could ride SQLite all the way into production if you wanted to.

I'd love to hear more about the ignoring column types/size limit/other issues that you've run into though, have you written about them anywhere or is there an SO post? I haven't run into anything super egregious though I've had some problems with FKs before.


Do a GROUP BY, and then try referencing a term which hasn't been either aggregated or mentioned in the GROUP BY clause. The result should be "abort! this query can't make sense!". The result (last I tried) is instead "sure, here's some arbitrary value from this group".


Foreign keys are supported with SQLite version 3.6.19 onward (~late 2009), though not enabled by default.

https://sqlite.org/foreignkeys.html

If you can add "PRAGMA foreign_keys = ON;" to your testing script SQL calls - somewhere soon after connecting to SQLite - that enables it.


It seeks to replace fopen() not postgres.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: