Hangfire: Default Schema

[tbasallo]

Is there is a reason that a default schema of "Hangfire" is hard coded? I am currently using a single database for multiple applications (due to database cost) and each application has it's own default schema per the application login. Applications do not have access to other schemas. (multi-tenant database).

If I wanted to use Hangfire for any of the applications, they would each create the required objects. However, with the hardcoded schema this is not possible (and the schema needs to have access to the Hangfire schema).

I see two solutions:

• Use the connections default schema
• Provide the ability to use a custom schema

Before going forward, I wanted to make sure there wasn't a reason this wasn't initially implemented.

[odinserj]

Simplification is the only reason for the hard-coded schema. Would you like to create a PR with ability to use custom schemas in SQL Server?

[tbasallo]

Yes, I can work on that. I think that setting it as an option in SqlServerStorageOptions would be the best way. Do you agree?

Also, since the table names are quite simple and potentially common, to avoid conflicts, would you have issue with an additional option to provide a table prefix?

[odinserj]

Yes, I can work on that. I think that setting it as an option in SqlServerStorageOptions would be the best way. Do you agree?

Yep, I totally agree.

Also, since the table names are quite simple and potentially common, to avoid conflicts, would you have issue with an additional option to provide a table prefix?

Several people already asked for custom schema feature, that is why I readily agreed with this feature. However, nobody asked for custom table name prefixes yet. So I think we should discuss more about this before implementing them. I really don't like features, I trait them as a necessary evil, where the key word is _necessary_. Can you tell me why you can't avoid using custom prefixes?

[tbasallo]

The reason I think this will become necessary is that when we introduce custom schema or potentially a default schema (dbo) there is a higher risk of table name conflicts. For example, there are tables named Job, list, set, schema - these are common words that may already exist from other libraries or even from the app itself. Since you have been using the Hangfire schema, the chances for a conflict have been pretty low, but that will no longer be the case.

Another option would be to have a hardcoded prefix to prevent the conflicts based on the Hangfire schema version (I think this possible, not sure how you're using the versioning yet). We could then rename the tables something like HangfireJobs, HangfireList, etc. With a hardcoded prefix, it will not be an additional feature, just a change to table names. We could use defaults based on version. The breaking change here would be for people that have written custom SQL against the tables.

[odinserj]

@tbasallo, multiple schemas are now supported since 1.5.0-beta4, thanks to @ryanmwright! Table prefixes can be also implemented in the same way. I agree with you that they may be necessary.

[sk29110]

How can I achieve this? I want to change the name of database and add prefix to default ones. Unfortunately there is no document.

[simeyla]

The docs are very lean. Kind of frustrating. You can specify the schema name like this:

        services.AddHangfire(x => x.UseSqlServerStorage(CONNECTION_STRING, new Hangfire.SqlServer.SqlServerStorageOptions
        {
            SchemaName = "Hangfire2"
        }));