Hangfire + Multitenancy tenant / database support or suggestion

[mohitook]

Hello,

Just found your boilerplate code and considered trying it based on my problem and your offered features:
Multitenancy + Hangfire support.

Currently there is not even one stable code sample which could support multitenancy with multiple database per tenant and hangfire recurring jobs (many ways to consider but everything falls apart quickly). Do you have a plan to make some examples or do yo have any suggestion where to look at?

Thank you in advance!

[iammukeshm]

multiple database per tenant ?

[iammukeshm]

In this boilerplate,
We have a root database (core database) that has Hangfire data. The root database will also have Identity Tables for the root tenant and any other tenant that uses this database.
You also have an option for tenants to have a separate database.

[mohitook]

I see. So as I understand right now this boilerplate solution doesn't have any suggestion for running Hangfire on database per tenant approach.
Thank you. I had a little hope this project can move me in the right direction when having this approach and recurring Hangfire jobs.
(Making dbContext for every tenant in recurring jobs is not as easy as we thought)

[Lokman-Simsek]

multiple database per tenant ?

Hi Mukesh
Is it possible to make multiple databases for each tenant?

[iammukeshm]

@Lokman-Simsek No . That actually doesn't make sense to be honest. Each tenant can either have a single database or can use a shared database.

[Lokman-Simsek]

Actually, what I wanted to ask was something like this.

Let's say there are 3 separate projects. (CRM, Finance and Personnel operations). There will also be a database with common definitions to be used in each project. (For example, department definitions.). There will also be rootTenantDb with users, tenants and other information.

These 5 databases will be combined into a single webapi. Thus, when a user/tenant is defined, he/she will be able to login in all 3 projects and operate in line with the roles given. Especially when the Common definition is made, it can be used in the other 3 projects. Thus, the user definition will be made once and will be active in more than one project.

Separately for each 3 projects
Small-capacity tenants are identified in common databases (separated by the tenant column). Large-capacity tenants will operate in a separate database.

I hope I was able to write what I wanted to explain fully with my bad English.

[frankyjquintero]

Según lo que puedo apreciar es la necesidad de que cada inquilino tenga su propio esquema de base de datos de hangfire quizás por el impacto que este tiene cuando un inquilino tiene cientos, miles o millones de tareas, otro tema es aquellos inquilinos que prefieran redis para estos casos. Lo que no sabría es si esto es posible por la forma en que está construido hangfire

[frankyjquintero]

@mohitook @iammukeshm una posible separación de Hangfire seria algo así:

#155

[frankyjquintero]

#166 Hangfire: Multi tenant resolving the correct(ApplicationDbContext and Services) for tenant on BackgroundJob

@mohitook
Based on your main need to solve the dbcontext for each tenant through dependency injection, I have created this solution that I would like you to test