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

Active? #9

Closed
adamhathcock opened this issue Nov 21, 2020 · 1 comment
Closed

Active? #9

adamhathcock opened this issue Nov 21, 2020 · 1 comment

Comments

@adamhathcock
Copy link

This looks interesting and a bit active. With the churn on dotnet 5 and be using a non-official hangfire storage, an EFCore solution would be better.

Does this work well? What issues do you have? I don't mind helping out on some outstanding work if there's any.

@sergezhigunov
Copy link
Owner

Yes, this is well tested and appears to be in some demand.
However, EFCore has several limitations that force you to choose for provider-specific implementations like Hangfire.SqlServer, Hangfire.PostgreSql and some others. For example, using optimistic concurrency when capturing a queue item is not as performant as when using an update query that returns output. There is a related issue #3.
Another issue #1 is that EFCore uses provider-specific migrations by design and it is quite problematic to create provider-neutral migrations.
And the next issue #2 is that most Hangfire queue implementations depend on Hangfire.SqlServer, where the queue service interface depends on TFM, which can lead to non-obvious consequences in complex dependency graphs.
I will be glad for any help or idea, if you have something. Thank you in advance.

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

No branches or pull requests

2 participants