Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why use SQL for config #5

Open
cryptix opened this issue Feb 18, 2014 · 9 comments
Open

Why use SQL for config #5

cryptix opened this issue Feb 18, 2014 · 9 comments

Comments

@cryptix
Copy link

cryptix commented Feb 18, 2014

Hi,

why do you use SQL to store configurations. Wouldn't JSON or INI work as well?
Would also remove the cgo deps.

@laurent22
Copy link
Owner

It's not so much the configuration, it's for the history data required by the undo feature.

Currently, it's saving each renaming operation for up to 7 days, so that could become quite large and it would be inefficient to store this in a text file. Actually, I'd rather not use cgo but I can't really think of a good alternative. I'm definitely open to suggestions though since not having cgo would simplify the cross-platform build process.

@laurent22
Copy link
Owner

So far I still haven't found a good alternative to SQLite so will keep using this for now.

@dufferzafar
Copy link
Contributor

@laurent22 You could use a JSON or INI just to store settings like editor and use_trash and use SQL for renaming history.

There are several benefits in using a text based config format - the most obvious one is, that I don't have to use commands to modify config settings, I could just open the editor (which massren loves doing anyways 😉) and modify things.

I might have been able to quote the path properly in the file and avoid #19

@laurent22 laurent22 reopened this Jul 25, 2014
@laurent22
Copy link
Owner

That's a good point. I'm reopening the issue in case someone is motivated enough to do a PR :)

@staticshock
Copy link

I second this request. I try to keep app settings in a dotfiles repo (and so do many others,) but I have zero interest in keeping the undo history, because that falls more into the "state cache" category and not the "settings" category. Settings generally benefit from being strictly separated from misc application state.

@laurent22
Copy link
Owner

@staticshock, I think that's indeed the right way to look at it. There should be cached/state data and config, and it should be two separate files. If I have time to do it (or, as always, if someone is motivated), that's how I'd do it:

  • Move all config data to INI file (or something similar to Git config files)
  • Move all history file to non-cgo dependant key/value store. The recently released Bolt I think would be a good candidate for this (https://github.com/boltdb/bolt)

@Vincevrp
Copy link

I try to keep app settings in a dotfiles repo (and so do many others,)

Exactly. @laurent22 Is there any update on this?

@laurent22
Copy link
Owner

I won't implement this myself as the current solution for my needs is good enough, but if someone submit a pull request I'll most likely accept it.

@laurent22
Copy link
Owner

The recently released Bolt I think would be a good candidate for this (https://github.com/boltdb/bolt)

Note: that project is dead now so we'd need something else

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants