Just noticed an issue with not nullable numeric types when editing.
When creating a new entity with RAD generated ui allows us to leave numeric (int, decimal etc) blank and when you save the content as those blank properties are not included in the request payload the backend uses the default values for those properties to save them in the db without any exception. However when it comes to edit the entity those properties are filled with default values (0). When you clear those default values (leave the fields blank) then hit the save button you get the exception as something like "Error converting value {null} to type 'System.Decimal'. "
What would be the best way to ignore those little annoying execptions? I assume that if the UI wouldn't let us click the "Save" button when those fields are empty (form is not valid by adding required) that would be a solution. But somehow even those fields are required it allows to save them in the first instance as empty. Maybe RAD generator should be changed to make those fields required?
Regards
Yes indeed! Should we wait for the solution or we can do something about this?
When advanced filter section is used to filter grid by any date time filter(min, max etc) then the filters are cleared to hit search or enter the client side throws exception as 'The parameter 'minDateFromFilter' cannot be null.'.
I think the date should be set to undefined when cleared instead as the generated 'service-proxies.ts' checks for dates against null and throws the exception.
Reproduce step:
1- Use RAD tool to generate an Entity (make sure to select filters by a property that type is date) 2- Once the pages are created go the list of entities 3- Expend the 'Advanced filters' on the page 4- Filter by a date property and hit the enter. 5- Remove the date field and hit the enter
Now you will see a spinner on the page and when you view the F12 you will see the error on the console that shows you that the date is null.
Finally worked! Even though the DefaultConnectionString still shows the default conecttionstring in the instance of _testMigration but the result is that the second database gets the migration with following registering.
Thanks
IocManager.IocContainer.Register( Component.For<IConnectionStringResolver, IDbPerTenantConnectionStringResolver>() .ImplementedBy<MyDbPerTenantConnectionStringResolver>() .Named(Guid.NewGuid().ToString()) .IsDefault() .LifestyleTransient()
Nope. Still the default connection string points to the default one...
Both AbpZeroDbMigrator instance and TestAbpZeroDbMigrator instance contain the same default database connection string. I assume this shouldn't be the case.
Configuration.ReplaceService<IConnectionStringResolver, MyDbPerTenantConnectionStringResolver>(); line doesn't seem to have any affect. I tried put the line in .EntityFrameworkCode module PreInitialize method and also tried it in Migrator module but still no luck.
In .EntityFrameworkCore there is already Default module one as below
Configuration.ReplaceService<IConnectionStringResolver, DefaultDbConnectionStringResolver>();
here is well _connectionStringResolver always points to default database connection string.
I started doubting that Migrator can be used to apply migration to multiple db context.. ?
thanks :)
I tried this but the instance cannot be created with the following error. Not sure how I should register this in Migrator project.
Message "Can't create component 'Project.Migrator.MultiTenantMigrateExecuter' as it has dependencies to be satisfied.\r\n\r\n'Project.Migrator.MultiTenantMigrateExecuter' is waiting for the following dependencies:\r\n- Service 'Abp.Zero.EntityFrameworkCore.AbpZeroDbMigrator 1[[Project.EntityFrameworkCore.APLBillingDbContext, Project.EntityFrameworkCore, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]]' which was not registered.\r\n" string
I have followed the same pattern and created SecondDBMigrator class as below:
public class SecondDBMigrator : AbpZeroDbMigrator<SecondDBContext>
{
public SecondDBMigrator(
IUnitOfWorkManager unitOfWorkManager,
IDbPerTenantConnectionStringResolver connectionStringResolver,
IDbContextResolver dbContextResolver) :
base(
unitOfWorkManager,
connectionStringResolver,
dbContextResolver)
{
}
}
```
With this I don't get exexption but when I look at instance of the migrator connection string in debug mode I see the default database connection string registered instead of second database.
Is there any way to apply migration to multiple db context by using Migrator tool? I don't mean for multi tenant applicaiton. In the application we disabled multi tenant but we have another dbcontext that we would like to apply migration through Migrator.
I would appriciate if you could point me right direction or anyone has this issue.
I have seen here Ismail suggested adding another tenant but I don't find this a good way as this requires storing connection string in database.
Ok I did a bit more investigation on this and I think i found what causing the issue. I guess it is a bug.
What I did is to disable all other languages( including englis-en) but en-GB. As we do not want to use localization. This is causing the message. As soon as I enable english (en) then I get the same error message with you.
Maybe this should be another question but is there any other place we should disable the localization and just make the default en-GB?