Thank @maliming.
The example use the "core" quartz implementation.
I'm using aspnet zero and I need to use IAbpQuartzConfiguration that has the scheduler instance used through the application. But the IAbpQuartzConfiguration is not available at startup time (in startup.cs in web host project).
So, how can I pass to app.UseCrystalQuartz(() the Scheduler used in aspnet Zero to view in the UI the triggers and jobs?
Thanks
Sorry @ismcagdas, my question isn't clear.
My problem is how obtain the "scheduler" instance on startup.
app.UseCrystalQuartz(() => scheduler)
I'm aware that the UI isn't for Angular.
Thank you.
I'm not an expert of Swagger and the default values works well for me until last update.
I must use options.CustomSchemaIds(o => o.FullName) because we have some duplicate schemaIds in our dtos otherwise I have the Conflicting schemaIds error.
If you want to see for enums the text instead of the values, I use options.DescribeAllEnumsAsStrings(); and all enum are showed as text:
Uno.Foundation.Core.ImageSizeTypestring $ref: #/definitions/Uno.Foundation.Core.ImageSizeType Enum: [ Big, Medium, Small ] <--- 1,2,3
Also swagger show a dropdown with literal values when you try some rest api. Maybe it is a duplicate functionality?
No, the code is the same and the problem happens in SwaggerOperationFilter.cs file.
Removed the new option all works fine. What is the purpose of this new code?
Thanks
Hi @ryancyq and @ismcagdas We have investigated more deeply in source code and probably found a solution thas is also an ANZ standard. Please tell me what do you think about.
[AutoRepositoryTypesAttribute(typeof(INullRepo<>), typeof(INullRepoKey<,>), typeof(NullRepo<>), typeof(NullRepoKey<,>), WithDefaultRepositoryInterfaces = false)]
INullRepo, INullRepoKey don't do nothing so the IRepository is not registered twice and at runtime is used the only one configured in the owner repository (so only one class and one configuration)
Our tests look good but I would like to hear some thoughts from your team. Thank you.
@ismcagda Do you have some thoughts about this?
Yes @ismcagdas you are right.
Due to the fact that is not possible join two different context, we have created a new QueryContext that has the responsability to make all cross context queries.
The use of dbContextProvider.GetDbContext().Set<YourEntity>().... is suitable for our requirements, but the side effect is that another context fails to retrive the correct IRepository because is registered twice.
What we think that could resolve the issue is the possibility to NOT register the IRepository for all the dbsets on the QueryContext but only for the all other contexts (For example with an attribute in the context that skips the registration). This solution could also resolve the huge problem of very slow startup when you need to resolve many respository in ctor.
Hi, Some update about this topic?
Thank you.
Hi @maliming sorry I didn't report the link to the previous thread
What you say is what we are doing now and you said that is a valid solution, but is a workaround and we are loosing the IRepository behaviours. Every "deviation" to the standard path/architecture can cause problems in the future if the implementaion changes, and as our project is very big, we dont' want to take the wrong way. How would you solve the problem?
There is a flipside with this workaround? Is compatible with what have you planned for the next releases ? This is our main fear.
Thank you.
Awesome. Thank you aaron