Hello, I narrowed this down to "Tabify" changes in the DbContext file located in EntityFrameworkCore-project. If I do indentation with spaces, the generation works. I can get the generation to go through if I indent the public "DbSet<AppUser> Users { get; set; }" line with spaces and other lines with tabs. Knowing this, we can work around this, but it would be interesting to know why this happens and what would be the correct way to handle this.
Hi, I see and thank you for your answer. Since we are just starting the project, the DbContext.cs file is what comes out of the project generation and only the style changes were made to it. No entities were generated yet.
I also came up with another problem with the GRUD geneation: I generated the solution with a name "ABC". This ABC represents context of the whole solution. Inside this I whould like to change the projects' names (other that Host and DBMigrator) to better describe our core context so our project structure would look like this: ABC.DbMigrator ABC.HttpApi.Host ABC.IdentityServer ABC.CoreContextName.Application ABC.CoreContextName.Application.Contracts ABC.CoreContextName.Domain ABC.CoreContextName.Domain.Shared ... and so on After this chage the generation stopped working. What would be the suggested solution to this problem or is there any at the moment?
Hi Albert, thank you for the answer. We tried it that way but the problem with that approach is that it's not easy to populate all the value object data to a grid showing parent entity's data. Going the other route and defining the value object's properties separaterly to the parent entity and then changing backend code to form a value object, also needs a lot of customization to the generated code. Either way having to change the code after generation ruins the maintainability of the entity (with suite). Thus we desided not to use Value Objects at this point and describe the data as separate properties inside the parent entity. Unfortunately this deficit undermines our domain model a bit :(
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?
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?
Not publicly unless I do a new similar but generic project.
OK, I have done that. How can I share this with you?
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);
}
}
};
}
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.
And we should always set the tenant Id as well?