Hello,
this https://docs.abp.io/en/abp/latest/Multi-Tenancy#imultitenant is not very clear on how should we do multitenancy in "Database per tenant" environment.
If we know that we are not going to share our data accross tenants, can we disable multitenancy all together? If not, should only the aggregates be multitenant or entities under aggregates as well?
This came up in a situation where we had both an aggregate and it's entity defined as IMultitenant but our logic only set the aggregate's tenant id in creation. This created a situation where aggregate's GetAsync, sub collection included, never populated the subcollection. Removin the IMultitenant defintion fron the entity fixed this. This got us thinkin do we still need to define aggregates and entities as multitenant if we know that tenant data will always be separated in tenant specific database?
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);
}
}
};
}
ABP Framework version: 4.4.0
UI type: Angular
DB provider: EF Core
Tiered (MVC) or Identity Server Separated (Angular): yes
**Exception message and stack trace olo.Abp.AbpInitializationException : An error occurred during the initialize Volo.Abp.Modularity.OnApplicationInitializationModuleLifecycleContributor phase of the module Volo.Abp.Quartz.AbpQuartzModule, Volo.Abp.Quartz, Version=4.4.0.0, Culture=neutral, PublicKeyToken=null: An exception was thrown while activating λ:Quartz.IScheduler.. See the inner exception for details. ---- Autofac.Core.DependencyResolutionException : An exception was thrown while activating λ:Quartz.IScheduler. -------- Quartz.SchedulerException : Scheduler with name 'QuartzScheduler' already exists.
Stack Trace:
ModuleManager.InitializeModules(ApplicationInitializationContext context)
AbpApplicationBase.InitializeModules()
AbpApplicationWithExternalServiceProvider.Initialize(IServiceProvider serviceProvider)
AbpIntegratedTest1.ctor() BackgroundProcessesTestBase1.ctor()
SchedulerCreationFailingTestExample.ctor()
----- Inner Stack Trace -----
ActivatorErrorHandlingMiddleware.Execute(ResolveRequestContext context, Action1 next) <>c__DisplayClass14_0.<BuildPipeline>b__1(ResolveRequestContext ctxt) ResolvePipeline.Invoke(ResolveRequestContext ctxt) <42 more frames...> AsyncHelper.RunSync[TResult](Func1 func)
<>c.<ConfigureServices>b__1_1(IServiceProvider serviceProvider)
<>c__DisplayClass3_0.<Register>b__0(IComponentContext context, IEnumerable1 parameters) DelegateActivator.ActivateInstance(IComponentContext context, IEnumerable1 parameters)
DelegateActivator.<ConfigurePipeline>b__2_0(ResolveRequestContext ctxt, Action1 next) DelegateMiddleware.Execute(ResolveRequestContext context, Action1 next)
<>c__DisplayClass14_0.<BuildPipeline>b__1(ResolveRequestContext ctxt)
DisposalTrackingMiddleware.Execute(ResolveRequestContext context, Action1 next) <>c__DisplayClass14_0.<BuildPipeline>b__1(ResolveRequestContext ctxt) ActivatorErrorHandlingMiddleware.Execute(ResolveRequestContext context, Action1 next)
**Steps to reproduce the issue:
I'm tring to unit test my Quarz background workers. Whenever I run multiple tests where I initialize a backround worker the tests fail because the IScheduler is already created with another test. My tests are integration tests since I need some registered services in my workers. I dosen't make a difference if I use a new scheduler for the actual scheduling in my tests like this:
IScheduler scheduler = await GetNewScheduler();
// Act
ISchedulerListener listener = Substitute.For<ISchedulerListener>();
scheduler.ListenerManager.AddSchedulerListener(listener);
await worker.ScheduleJob.Invoke(scheduler);
My test module depend on a module that depends on AbpBackgroundWorkersQuartzModule and through that the Quartz gets initialized. It seems to me that AbpIntegratedTest initialization doesn't take into account that the Quartz cannot be initialized multiple times. I realize that this is possibly a Quarz problem but is there a some way to change the Quarz initialization so that IScheduler implementation will be initialized only once.
OK, I have done that. How can I share this with you?
ArgumentNullException: Value cannot be null. Arg_ParamName_Name (ConnectionString)
I created a new console application with the cli generator. After that I created a module that depends on the settings module. Apparently this brings a dependency to SettingManagementDbContext. My intend was to create a unit test module to test the module and I mimiced the Domain.test -project initilaziation from another application. However this time the initilization wants to use the real database instead of the in memory -database for SettingManagementDbContext.
What should I do in the test base initialization to make a generic module to use in memory-database?
Not publicly unless I do a new similar but generic project.
I Have two questions:
public class TenantCalculationTimeSettingProvider : SettingDefinitionProvider
{
public override void Define(ISettingDefinitionContext context)
{
context.Add(
new SettingDefinition("CalculationTimeCronConf"
, "0 */1 * ? * *"
, new LocalizableString(typeof(TenantCalculationTimeSettingProvider), "configuration for time scheduled calculation")
,new LocalizableString(typeof(TenantCalculationTimeSettingProvider), "configuration for time scheduled calculation")
));
}
}
I cannot get the Define-method to fire no matter what I try. I have added the dependency to AbpSettingsModule and tried to register the provider manually
public override void ConfigureServices(ServiceConfigurationContext context)
{
Configure<AbpSettingOptions>(options =>
{
options.DefinitionProviders.Add<TenantCalculationTimeSettingProvider>();
});
}
If I add the same provider in my main web application it works. I'm I missing some dependency in my new application for the Define to work?
2 If I define the setting this way, is there an Angular component (In commersial package perhaps) that enables viewing and editing this setting?
Hello, is there a reason why no foreign key constraints are create from the audit fields CreatorId and LastModifierId to the user? Is is preferred to keep that way or could we add such contraints? Our use case is to show the last updater user in UI.
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?