Same job type with different job-data skipped about hangfire.recurringjobextensions HOT 9 CLOSED

@gyzmau
Thanks for your feedback.
When we use json config ,the json settings token job-name is equals to RecurringJobId.
As your said to store recuringjob info with the key JobId by extension method GetRecurringJobId cannot distinguish same job-type, because same job type has the same JobId with GetRecurringJobId.
I think using the specified job-name as the key is proper, it will do this later.

from hangfire.recurringjobextensions.

Edit: i did this reply without seeing your previous comment, i will reply about your suggestions, not sure we have the job-name in the OnPerforming .

I think we should have two ways to solve this problem:

• First one, the save/update of jobs in the underlying storage should be done before the Init of the filter, and the init of the filter should be done with JobInfos from the underlying storage of Hangfire. In this way using the Id of the underlying storage.
• Second one, use the Args property to put our RecurringJobId and like this have a way to finding it back.

The first one is cleaner but ask for a big refactor in the way that RecurringJobExtensions is working.

The second one is less less evasive but more dirty in the concept. And I dunno enough about Hangfire and the Args property to know if we can use it.

Do you have any suggestion @icsharp ?

from hangfire.recurringjobextensions.

@gyzmau
Hangfire add/update recurringjob depends on recurringJobId, if you know the the Hangfire class RecurringJob static method:

public static void AddOrUpdate(string recurringJobId, Expression<Action> methodCall, Func<string> cronExpression, TimeZoneInfo timeZone = null, string queue = "default");

The first parameter recurringJobId is the identifier of recurringjob, so the key point is how to distinguish
job by recurringJobId.

For your first way, it is noting to do with hangfire storage. RecurringJobExtensions provider the way to
define the recurringjob info and job-data info in json file, or you can impl the interface IConfigurationProvider to custom your storage to store you recurringjob info.

The second way as you mentioned , maybe it is proper to use RecurringJobId as job-name in json file to instead Args property.

Maybe your scenario can simply to define two different recurringjob to avoid the same job type.

from hangfire.recurringjobextensions.

@gyzmau
Maybe it is also not proper to use job-name as the key, because it cannot find it back in PerformContext.
Simply way is to define two different recurringjob to avoid the same job type.

from hangfire.recurringjobextensions.

@icsharp yes I confirm about the performContext

I agree it will be simpler to do different types of Job. But if i do that I will lost completely the benefit of RecurringJobExtension (In the way i see it).

For example if you have simple task to do on three different countries.
It will be very counterproductive to do a RecurringJob class by country for the same task.
if I have to do job "strong typed", It will be the same at the end as Hangfire, I like the fact that i just code a simple task that i can apply to different parameters.

I could as well, do one Job who take care of all, but again i like the flexibility that you can launch only one country, especially in case of failure (you can relaunch one).

I need to go a bit further and dig a bit deeper to have better idea. It might be an issue on hangfire design as well (Totally an assumption i dont know at all hangfire codebase).

from hangfire.recurringjobextensions.

@gyzmau
I have checked the hangfire source code, all jobs(Fire-and-forget jobs/Delayed jobs/Recurring jobs etc.) are fetched from storage and have the same job payload. Hangfire server executed job depends on job method and its args. In other words, the PerformContext is the common design for all jobs, not only the recurring jobs.
For your example, I have not a good idea to solve yet, maybe you can impl your business logic in another way.

from hangfire.recurringjobextensions.

@icsharp yes i reached the same conclusion, Its more by design on the Hangfire side.

I am trying to figure out if i can use the Args of a job.

Thanks a lot for having a look at it!

from hangfire.recurringjobextensions.

@gyzmau
I have fix it , see v1.1.5.

from hangfire.recurringjobextensions.

Oh awesome! I will check tomorrow.
Thanks you a lot!

from hangfire.recurringjobextensions.