Activities of "alexander.nikonov"

Mosf of the time - when we have a technical question - we are asked to either send the project source code or create the test version where the problem is reproduced.

The first one is not possible because of commercial nature of the project. The second one is very time consuming and is not possible too.

Yes, our solution is quite complex and we have some custom code on the top of ABP framework. But it would be great, if your support team devoted more time trying to understand the nature of the problem and analyze the fragments of the code shown in the message. Because often the answers are very short and meaningless - so we end up debugging out solution and looking at the downloaded ABP module source codes to resolve the problem ourselves.

p.ClrType == typeof(ExtraPropertyDictionary)

That was it. I was checking against string type only, would not expect such ClrType. Seems like I finally got rid of NVARCHAR. Thank you. I will keep this ticket open for some time until the migration is done...

And again you don't understand what I'm trying to say. I'm telling you that migration using a standard driver causes problem now. I have shown you the fragments of the code. Migration with Devart which has always been used never caused the problem. But now Devart cannot be used, they delay the NET7 support for month or so. You have published ABP7, but rely on Devart. Can you offer a working migration solution NOW?

Ok. But that was not my main question. My main question is why output generated by Devart differs from the standard one? They are supposed to be identical. Are you saying that output generated by standard driver is incorrect and cannot be used for Oracle migration??

Unfortunately, we don't have time and need to migrate now. So we need to use a generic Oracle driver. The script which is generated by the generic driver, looks weird, though - it suggests to replace VARCHAR fields in ABP tables with NVARCHAR. There are a lot of such changes. Could you please explain, why in a 7.0.1 test app you are suggesting to use NVARCHAR/NVARCHAR2 DB type:

but at the same time the suggested Devart-based DB configuration has the following options, i.e. the DB fields are generated as VARCHAR/VARCHAR2?

So currently the generated migration script has tons of suggested changes like this (it compares the previously created migration using Devart and a generic dviver generation now):

I've tried to get rid of NVARCHAR manually in the DB migration context:

    protected override void OnModelCreating(ModelBuilder builder)
    {
        //var config = Devart.Data.Oracle.Entity.Configuration.OracleEntityProviderConfig.Instance;
        //config.Workarounds.DisableQuoting = true;
        //config.CodeFirstOptions.UseNonLobStrings = true;
        //config.CodeFirstOptions.UseNonUnicodeStrings = true;

        base.OnModelCreating(builder);

        /* Include modules to your migration db context */

        builder.ConfigurePermissionManagement();
        builder.ConfigureSettingManagement();
        builder.ConfigureBackgroundJobs();
        builder.ConfigureAuditLogging();
        builder.ConfigureIdentityPro();
        builder.ConfigureIdentityServer();
        builder.ConfigureFeatureManagement();
        builder.ConfigureLanguageManagement();
        builder.ConfigureTextTemplateManagement();
        builder.ConfigureBlobStoring();
        builder.ConfigureSaas();
        
        foreach (var property in builder.Model.GetEntityTypes().SelectMany(e => e.GetProperties()).Where(p => p.ClrType == typeof(string)))
        {
            property.SetIsUnicode(false);
        }
    }

But it still generates me migration script with NVARCHAR/NVARCHAR2...

This does not help either:

    protected override void ConfigureConventions(ModelConfigurationBuilder configurationBuilder)
    {
        configurationBuilder.DefaultTypeMapping<string>().IsUnicode(false);
    }

hi

I think there is no problem with this.

Restore my question points then please if not done yet.

Eventually I've resolved thie issue. I've split the shared project DbContexts into 2 - one contains the entities which are shared in the consuming project, another one contains the entities which use the same table as the entities in the consuming project. Please, replenish my point for this question.

I've tried to resolved the issue with the code below (separating DbContexts):

public static void ConfigureCoreInternal(this ModelBuilder builder, Action<CoreModelBuilderConfigurationOptions> optionsAction = null)
...

EntityFramework Module:

[DependsOn(typeof(CoreDomainModule), typeof(AbpEntityFrameworkCoreModule))]
public class CoreEntityFrameworkCoreModule : AbpModule
{
    public override void ConfigureServices(ServiceConfigurationContext context)
    {
        context.Services.AddAbpDbContext<CoreDbContext>(options =>
        {
            options.AddDefaultRepository<ModuleLicence>();
            options.AddDefaultRepository<CompanyLicence>();
            options.AddDefaultRepository<Tenant>();
        });
    }
}

The method which does DB work:

public async Task<List<string>> GetAccessibleModulesAsync(int abxTenantId)
{
    using (var uow = _unitOfWorkManager.Begin())
    {
        var tenants = await _tenantRepository.GetQueryableAsync();
        var companyLicences = await _companyLicenceRepository.GetQueryableAsync();
        var moduleLicences = await _moduleLicenceRepository.GetQueryableAsync();

        var query = from tenant in tenants.Where(x => x.Id == abxTenantId).Take(1)
                    join companyLicence in companyLicences on tenant.CompanyId equals companyLicence.CompanyId
                    join moduleLicence in moduleLicences on companyLicence.LicenceId equals moduleLicence.LicenceId
                    select moduleLicence.ModuleId;

        return query.Distinct().ToList();
    }
}

Application Module where I add my custom class AbxPermissionChecker:

[DependsOn(...., typeof(CoreApplicationModule))]
public class CentralToolsApplicationModule : AbpModule
{
    public override void ConfigureServices(ServiceConfigurationContext context)
    {
        var configuration = context.Services.GetConfiguration();

        Configure<AbpAutoMapperOptions>(options =>
        {
            options.AddMaps<CentralToolsApplicationModule>();
        });

        ....
        context.Services.Replace(ServiceDescriptor.Transient<IPermissionChecker, AbxPermissionChecker>()); // REPLACING ABP PermissionChecker!
    }
}

But still getting the above exception

What is a proper way of isolating entities in the DbContext of the project which is shared? Maybe this is the only root of the problem?

Or, I can keep using AppService - with RemoteService(IsEnabled = false)] as mentioned in my code, right? I do not expose NotificationAppService outside. In such case there's no difference between using it or converting it to DomainService, as far as I understand. I even don't inherit ApplicationService class...

Even if I use DomainService or Repository directly - how will it differ from using IApplicationService in the way I used it in terms of trust? I really need kind of pass "trust" from Received method into AppService (or other level) method where I would act on behalf of this user which usually is an authenticated ICurrentUser if used from frontend application. What I have at my disposal is just this user's Id and Tenant inside Received method.