Using a Database in a Package


#1

Is it possible to use a database within a package?

I’m developing Save Session, an package that will save your open files and contents (among other things), so that when you reopen Atom later, it gets restored. I’m afraid that just writing files to disk will eventually get slow.

So is there a database that Atom ships with that we can use or will users be required to download and install one if they want to use my package and I want to use one?

Thanks


#2

There is no db built into Atom. This looks interesting but I haven’t tried it.


#3

I was thinking of using this:


#4

Okay cool, I’ll look into that.


#5

Except the ones built into chrome ;):

And for simpler use case there’s still localStorage (already used by a bunch of packages).


#6

I think a database for that is pretty overkill… You shouldn’t have any problems just writing out your session to a JSON file. Databases have to go to disk eventually anyway, so it’s not going to be any slower.

localStorage would be OK although I’m wary of packages using that instead of storing their configuration in ~/.atom.


#7

I agree, but there are some legitimate use cases. A package that use serialization will be able to store data for a project, but won’t be able to access data created in another instance, so localStorage make sense if you need to persist things over many sessions/projects. For instance you can just store the path to the last opened project directories in localStorage, and on restart, if this field exist, you can use it to open the corresponding projects.


#8

Yeah, my only issue is if something goes wrong it becomes impossible to blow your configuration away and start again without going into the developer tools. Returning to a pristine configuration should be as simple as deleting ~/.atom.


#9

How much are you storing down though?

What’s the maximum of open files you might have to save down in your cache?
Plus, if you remove parts of caches dynamically as and when panes are closed, the whole thing should remain fairly manageable, no?


#10

I suppose it may be overkill, I had a bug report that said the package wasn’t saving when they had a lot of files open. I’m guessing that it is due to speed and I figured writing to a database is probably faster than just writing to a file myself. I’ll stick to what I have now until I really need to change it, if that happens.


#11

I haven’t seen your code, but maybe it’s the method of saving it that could be streamlined, maybe saving too much at once instead of little incremental updates?

Otherwise you’re probably right that storage in memory certainly won’t hurt.


#12

Well I don’t really want to save it to memory, so that it restores your work even if Atom crashes. So a database might not be too safe anyway…

So far, it saves all of your files you are working on every time you make a change, since it saves it all in a project.json file. I’m sure it would be better to save the files separately and then just have the project file remember what files were open. It was just a quick and easy way to handle it.