Choose an storage backend that does not depend on CGO

[xiam]

Currently Hyperfox saves data to a SQLite database.

This offers some benefits:

• Data is not locked to Hyperfox.
• Users can use a variety of tools to examine records.

But also carries some drawbacks:

• Easy cross compilation is not possible.
• Simple compilation is not that straightforward.

It would be nice to:

• Cross-compile Hyperfox easily to provide binaries for different OSs with no effort.
• Offer a readable database format (or exporting options), so the user is not locked to Hyperfox.

The database we choose:

• Must be embedded so it does not require any additional servers or programs to run.
• Must offer search and indexing capabilities.
• Must work fine with big blobs of binary data.
• Should accept date and time range queries.
• Should provide command line or visual tools for searching database files.

Some options to consider are boltdb, goleveldb and ql. I don't have a lot of experience with boltdb and goleveldb so any informed opinions on the matter would be very much appreciated.

[sergiodl]

Hello everybody,

Do we still have interested in implementing support for other databases in Hyperfox?
I think ql could be a good options, because, as far as I know, it does not depends on any native code.

The other options (linke goleveldb and boltdb) are still good, but the use a different data representation paradigm (they are nosql databases, while hyperfox is currently based on a sql database), so we would need to rethink the way hyperfox stores and queries its data.

[xiam]

Hey @sergiodl,

I still think it would be great to have support for other databases and while I think QL could be an option it has a downside: QL lacks third-party graphical user interfaces and the command line tool ql is not that easy to use.

QL is easier to use and to cross compile and I am more a command-line person, but I am also aware that lots of people prefer using graphical tools. SQLite is old and there are tons of graphical interfaces for it.

So, I actually don't have any strong feelings on whether we save data to a SQL or NoSQL database, we can rethink and rewrite that as you say, I think it would be more useful to focus on the accessibility for our end-users, that's why I listed the sets of features I would like to find in a database.

Must be embedded, so it does not require any additional servers or programs to run.
Must offer search and indexing capabilities.
Must work fine with big blobs of binary data.
Should accept date and time range queries.
Should provide command line or visual interfaces for managing database files.

QL would be perfect if the command line tool was not that awkward or if we had a graphical interface for users who prefer them over the command line.