zellyn
commented
6 years ago Your use-case is very similar to mine, which is reading browser cookies. Wanting to avoid the heavyweight C-linked sqlite libraries is exactly why I started contributing to this project. For now, I just punted on column names completely, and trusted that I could rely on the number and order of column data, and the type information attached to it. Here's the code in question: https://github.com/zellyn/kooky/blob/master/chrome.go#L26
Your code (and the existing comma-splitting code to count columns) will sort-of work, at least for simple table definitions. However, for more complex definitions, it will break down: you can see that table-constraint clauses are comma-separated here: https://www.sqlite.org/lang_createtable.html.
I was planning on writing a simple-as-possible parser that could handle the full sqlite create table syntax, and using that to extract structured information about the table. But then, you know, my cookie-reading code started working perfectly, and … well ¯\_(ツ)_/¯
sbinet
adamdecaf
Cool project. I want to read browser (firefox, chrome, etc) history sqlite databases and don't want to import a cgo library for the simple read. (It'll also complicate my build process)
To get my feet wet I found out a way to read column names, but I'm unsure if this works well enough.
My use case doesn't need to be "fast" and I only need one column's data from one table in these files.
I'm willing to help read tables/column data more.