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

feat: Support for SQLite backend #129

Closed
pranavmodx opened this issue Apr 29, 2024 · 2 comments · May be fixed by #130
Closed

feat: Support for SQLite backend #129

pranavmodx opened this issue Apr 29, 2024 · 2 comments · May be fixed by #130
Labels

Comments

@pranavmodx
Copy link

Hi Adriano,

Thanks for creating this amazing library! We have used it at our organization and it fits really well for our use cases.

The main requirement for us was that we needed a job queue backend which was persistent and embeddable in our application. As far as we could see, currently no job queuing library in Go has support for embedded databases like SQLite. So we were on the lookout to maybe extend an existing library or write one from scratch in the worst case. But thanks to the simplicity of neoq, we decided to implement SQLite backend for it to be able to use most (and eventually all) of neoq's features.

Here is the fork of neoq which implements SQLite backend: https://github.com/pranavmodx/neoq-sqlite
SQLite doesn't seem to have a built-in notification system as that in PostgreSQL (pg_notify). So I have used Go channels as a mechanism similar to how you have used it for in-memory queue backend. The overall changes may need some refactoring and addition of unit tests.

Would you be interested in reviewing this effort and considering it as an open source contribution?

Thanks,
Pranav

@acaloiaro
Copy link
Owner

@pranavmodx I'm absolutely interested in merging SQLite support. Thank you for contributing back!

A few things we should consider requirements for merging new backends

  • Feature parity with existing backends. I think some exceptions to this rule may be reasonable, but I'd like to deal with them on a case-by-case basis. Feature parity theoretically makes it easy to swap out different backends within one's application without needing to change much application code.
  • Roughly the same amount of test coverage as existing backends. I believe the existing backends are between 60 and 80% coverage right now. Which is actually lower than I'd like coverage to be, so asking for roughly the same coverage seems reasonable. But more would be better if reasonable.

Let's get your work under review whenever you're ready. Feel free to join the Matrix chat from the README if you want to discuss anything further.

Cheers

Copy link

This issue is stale. Feel free to re-open it if it requires more attention

@github-actions github-actions bot added the stale label Aug 16, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Aug 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants