search

orbitalci / orbital

Orbital is a self-hosted CI system for solo/small consulting dev teams. Written in Rust.
GNU General Public License v3.0
29 stars 2 forks source link

Refactor internal references of Storage to something more like Database #187

Closed tjtelan closed 5 years ago

tjtelan commented 5 years ago

Since support for "filesystem" as a backend was removed, the concept of "storage" is lost.

We use "storage" pretty much exclusively to describe Postgres. If we're going to keep this abstraction layer, then we should rename to help give better hints to the reader about what kind of data we are storing. Database is more explicit about how it is used than storage.

shankj3 commented 5 years ago

I wanted to reimplement different storage types in the future to reduce the deployment footprint

shankj3 commented 5 years ago

Like the backend types in vault

shankj3 commented 5 years ago

@tjtelan I think storage is still applicable so that we can implement different backend types and not be trapped to requiring a full database setup to try out using ocelot.. If this is alright I'd like to close this issue

tjtelan commented 5 years ago

That would be nice to have a non-postgres setup, but we currently do need a full database to try out Ocelot today.

Filesystem backend code wasn't ever implemented before being removed. I don't know who the user for this backend is, since we certainly never found it urgent enough to use it. I'm shopping around for potential users/contributors, so that's part of the reason why I set up Vagrant stuff to lower the barrier to try everything out.

It isn't that I don't think a filesystem-based database would work (though it would have harder to compare performance characteristics, and have inode constraints that Postgres doesn't have, but also a ton of flexibility a DB couldn't have). Acting as a flat-file or multi-file database, would continue to have database-like requirements from Ocelot's perspective (but using filesystem tree traversals rather than SQL). For deployment footprint arguments, sqlite or even a completely in-memory option would, personally, be more pragmatic.

But I am leaning more towards the pluggable backend type-like support, and using words allow that abstraction to exist narratively. Specifically, I'm not exactly seeing the end-game with FS.

Another issue that lays out the interface design as it would fit for would be helpful. It is the semantics of "storage" vs "database" that has me bothered. Our data is structured.

shankj3 commented 5 years ago

How is storage different than backend? Filesystem was our original storage type, yes it wasn't kept up because there were other needs. We also could use Consul as our storage type.

shankj3 commented 5 years ago

I am closing this out, we spoke about it over the phone, my main argument is: I specifically didn't use database because I wanted to allow for filesystem storage or kv storage, as database lends the conception of a database server not so much a kv store or filesystem as I'd like to expand to. If this ends up not being in scope we can repoen