Activities of "mightyit"

Hi @ismcagdas

No, it was not marked as an embedded resource. Will give it a go to see if it fixes this issue.

Thanks for the feedback!

Hi @aaron

Yes, I mean the scope of my migration.

The possible triggers for these migrations are (as far as I can see at the moment - I might be overlooking some):

• Running the migration console app
• Tenant creation

But I see what you are saying - I think your suggestion might work on tenant record creation.

Thanks for this!

Entity events are generic events that react to record create, update and delete events on entities. The scope of your event / UoW is thus limited.

The scope of our UoW is not limited to entity record create/update/delete for one entity at a time. The scope of our UoW is about performing schema updates and seeding across multiple entities, not a single record update.

@aaron As far as I can tell that convention is limited to entity changes (inserts, updates and deletes), not domain events.

It might also be useful, in future, to have the ability to register a MigrationProvider during the pre-initialize method of your module, which will then be invoked whenever your aplication needs to perform migrations.

For eaxample:

public class MyEfCoreModule : AbpModule
{
    public override void PreInitialize()
    {
        Configuration.Migrations.Providers.Add<MyEfCoreModuleMigrationProvider>();
    }

    public override void Initialize()
    {
        IocManager.RegisterAssemblyByConvention(Assembly.GetExecutingAssembly());
    }
}

This could work in a similar fashion than NavigationProviders currently does. This will remove the need for any directly-coupled code in dependent modules.

Thanks for the feedback, @ryancyq

I have considered domain events.

However, this will mean that each module migration will run asynchronously, which I think would create challenges in the following regards:

1. Tenant database creation/migration should occur in a single transaction. I think, but am not sure, that should a portion of this happen in an event handler (asynchronously) it will not form part of the transaction / unit of work. In the event that this fails for one of the modules, it could create issues since a full rollback will not occur.
2. User feedback - It will cause issues if the new tenant continues using the system if all module migrations has not yet completed successfully.
3. Controlling whether all handlers and their contained migrations fired and executed successfully could become a complex affair.

But perhaps there is an easy way to address these issues that I am not seeing?

In the meantime, I have implemented it as I described above and it works for now (but suggestions for better / correct ways are always appreciated)

One possible approach I have thought of, is to do the following:

• Create an IFooTenantManager: IDomainService, ITransientDependency interface in my FooModule.Core.Shared submodule, and an implementation FooTenantManager: ITenantManager in FooModule.Core submodule.

I can then use constructor injection in BaseModule to inject IFooTenantManager, as it will resolve by convention to a concrete instance of FooTenantManager.

Would this be the best approach?

Thanks for the feedback - it helped me to resolve the problem.

I renamed my AbpZeroDbMigrator class to MySystemDbMigrator. After changing it back, the service now successfully resolves.

It seems there is a hard-coded dependency on this class name to resolve the IAbpZeroDbMigrator service, correct? I would like to suggest that for issue resolution it would be most helpful if all DI and naming conventions / hard-coded project dependencies were documented in a single place.

Hi

Current module system is server side focused. For the client side, you can create a script/task to copy related view/script files. We have no such a code yet.

Is this still the case with version 4.1?