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

Sqlite Option #252

Open
meichthys opened this issue Jul 17, 2020 · 3 comments
Open

Sqlite Option #252

meichthys opened this issue Jul 17, 2020 · 3 comments

Comments

@meichthys
Copy link

Great work on this 🚀 I would like to suggest an option to use SQLite as the database. It would simplify the docker-compose and would be a little more light weight.

Feel free to close if you'd rather not deal with this.

@buhman
Copy link
Member

buhman commented Oct 9, 2020

I agree, sqlite would be better. Can't say I'll work on this myself anytime soon though 🙂 .

@buhman
Copy link
Member

buhman commented Oct 9, 2020

Another cool ideal might be to use ptpb/apocrypha as a storage backend (or support both sqlite and apocrypha at the same time, etc..)

@buhman
Copy link
Member

buhman commented Oct 9, 2020

I hacked a bit at the latter in #254.

#254 currently implements a stripped-down version of paste.get and paste.post functionality. This is just enough that a paste can be created, subsequently retrieved, and, for example, syntax highlighted. This is interesting from the perspective that syntax highlighting isn't a feature that I would consider reasonable to implement in ptpb/apocrypha, but probably makes sense in an "apocrypha proxy frontend".

It's clear a lot of the current ptpb/pb implementation is very entangled with how mongodb storage was implemented, and many of those details don't make sense in the context of other implementations.

Other notes to future self:

  • Flask url routing is ~incompatible with apocrypha's "base75" symbols--honestly anything not-Flask, even stdlib http.server would be more appropriate+better.

  • to reasonably support "non-database" backends like apocrypha, it is likely that some pb API features need to be removed or become optional--most of the features that are candidates for being dropped are obscure and were likely very rarely used anyway.

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

2 participants