أنشطة "LW"

I have no doupt that saving isn't a problem with this. To be clear, I haven't tried any solution yet, hence the "Design Question". However all the examples I have seen define the extraproperty name staticly and I'm trying to figure out if this king dynamic definition would work as well. If you have some sample code, I will gladly take a look at it :)

Hello, I think the JSON-field will suffice. But the problem isn't that can we map it to another table or not. The problem is that the meaning and value types change will change accross different tenants. For example: Tenant1 needs an additional property "SocialSecurityNumber" which is of type string but Tenant2 doen't care about that information. It needs an additional property "PersonLength" of type integer. We cannot know in advance what additional information each tenant needs, so the properties cannot be defined in advance like in the SetProperty-example. The JSON value would be created dynamically to the database by an external system (an integrator).

ABP Framework version: v4.4.3 Exception message and stack trace: No exceptions Steps to reproduce the issue: We have Project with Quartz for background workers and a project that contains Background jobs. The jobs are default Abp AsyncBackgroundJobs. With this configuration when ever I enqueue a background job to be excecuted, the excecution is done multiple times if background job excecution time exceeds the background job poll interval. If I unload the project that includes the AbpBackgroundWorkersQuartzModule, the background job is excecuted correctly (only once)

And we should always set the tenant Id as well?

Hi, that won't matter. For some reason the module initalization tries to initialize the scheduler twice if I have two tests. The problem is in the initalization, not in how I get the scheduler in my tests.

Hello, thank you for your answer. I wasn't quite clear on what I was testing. I'm not trying to test the Quarz library, I'm just using it as a tool in my test to assert my logic.

public Ctor(Guid tenantId, string tenantName, string scheduleDefinition)
		{
			Check.NotNullOrEmpty(tenantName, nameof(tenantName));
            Check.NotNullOrEmpty(scheduleDefinition, nameof(scheduleDefinition));

			JobDataMap jobDataMap = new()
			{
				{ "TenantId", tenantId }
			};
			JobDetail = JobBuilder.Create<ScheduledControlValueCalculationBackgroundWorker>()
				.WithIdentity(TenantSpesificBackgoundProcessNameFormat.GetFormattedName(this, tenantName))
				.SetJobData(jobDataMap)
				.Build();
			Trigger = TriggerBuilder.Create()
				.WithIdentity(TenantSpesificBackgoundProcessNameFormat.GetFormattedName(this, tenantName))
				/* 
				 * Put the schedule to the definition and do the rescheduling based on that info. No other easy way to check
				 * if the triggers are really the same. 
				 */
				.WithDescription(scheduleDefinition)
				.WithCronSchedule(scheduleDefinition, options => options.WithMisfireHandlingInstructionFireAndProceed() )
				.Build();
			
			ScheduleJob = async scheduler =>
			{
				if (!await scheduler.CheckExists(JobDetail.Key))
				{
					await scheduler.ScheduleJob(JobDetail, Trigger);
				}
				else
				{
					// If the job already exists there might be changes to the schedule so reschedule the job if so
					IJobDetail jobDetail = await scheduler.GetJobDetail(JobDetail.Key);
					
					var trigger = await scheduler.GetTrigger(Trigger.Key);
					if(trigger.Description != Trigger.Description)
					{
						await scheduler.RescheduleJob(trigger.Key, Trigger);
					}
				}
			};
		}

OK, I have done that. How can I share this with you?

Not publicly unless I do a new similar but generic project.

Ok, thank you. I get the impression that you would not prefer DbContext inheritance in any case. What problems do you see in that approach?

Thank you for your answer! Can you please clarify what this means "To not have problem in your migration, don't include this mapping in the unified migration." If I create the "dublicate" entity into module A. I have to have entity configuration to map the entity into the same table. How would I then exclude the configuration from migration creation?