Can we directly upgrade abp version without updating AspnetZero? we are currently on 8.1
We have not, but this was supposed to be supported in 5.1 too, and not really sure if anything has changed for EntityHistory between those versions.
Re-opening this, we are still having issues with TPH entity with an OwnedType
It does work when I add mappings in the CustomDtoMapper.cs in GraphQL. I was just curious if we could enable GraphQL without using AutoMapper at all. It sounds like that it not an option, unfortunately. Let me know if I'm mistaken.
We did not add the mapping in CustomDtoMapper, as we are bypassing the use of automapper altogether. We use the follow code to map entities to Dto:
public abstract class ViewEntityModel<TEntity, TViewModel, TPrimaryKey> : EntityDto<TPrimaryKey>, IViewModel<TEntity> where TEntity : class
where TViewModel : class, IViewModel<TEntity>, new()
{
public static TViewModel CreateFrom(TEntity entity)
{
var vm = new TViewModel();
vm.MapFrom(entity);
return vm;
}
public abstract void MapFrom(TEntity entity);
}
Is it possible to take advantage of GraphQL while doing custom mapping, or are we forced to use Automapper? Thanks.
I've read that documentation. What it doesn't provide is guidance around how to build dependencies that themselves depend on repositories if we want to leverage ABP's implicit UoW management. Are there best practices to follow around this beyond "don't use the repo in construcors"?
It is not reasonable, if even possible, to expect ABP or ASP.NET Zero to create a DB connection for every class that you inject.
There's clearly a different paradigm within ABP/A0 than with most other frameworks. Typically I wouldn't expect an IoC container to inject dependencies that aren't ready for use, but that seems to be the case here due to the implicit UoW management that ABP provides. The fact that this works under some circumstances but not others adds to the confusion - eg, removing the intermediate call to GetAllIncluding() and instead using onlyFirstOrDefault() results in a successful DB query via the repository.
I've read the UoW, DI, and Repository documentation for ABP, but I'm not seeing code examples or guidance on best practices are around how to implement a dependency that has its own dependency on a repository or dbcontext. Can you point me towards detailed documention or examples on how this should be done? Additional guidance would be appreciated.
Please elaborate. I'm not sure how expecting fully wired up dependencies to be injected into my own dependency injected class regardless of timing and calling safe methods within said dependency should require me to manage my own UoW.
While our original issue has been fixed in the upgrade to 8.1, we now have another bug when adding new migrations. Here are the steps to reproduce this issue on a clean demo project of v.8.1:
The migration adds the following column:
migrationBuilder.AddColumn<int>(
name: "EditionPaymentType",
table: "AppSubscriptionPayments",
nullable: false,
defaultValue: 0);
Because of this column, running update-database produces the following exception:
Column names in each table must be unique. Column name 'EditionPaymentType' in table 'AppSubscriptionPayments' is specified more than once.
Here is the Stack Trace for the exception:
Applying migration '20200102200758_Add_User_With_Address'.
Failed executing DbCommand (7ms) [Parameters=[], CommandType='Text', CommandTimeout='30']
ALTER TABLE [AppSubscriptionPayments] ADD [EditionPaymentType] int NOT NULL DEFAULT 0;
Microsoft.Data.SqlClient.SqlException (0x80131904): Column names in each table must be unique. Column name 'EditionPaymentType' in table 'AppSubscriptionPayments' is specified more than once.
at Microsoft.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
at Microsoft.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
at Microsoft.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
at Microsoft.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
at Microsoft.Data.SqlClient.SqlCommand.RunExecuteNonQueryTds(String methodName, Boolean isAsync, Int32 timeout, Boolean asyncWrite)
at Microsoft.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(TaskCompletionSource`1 completion, Boolean sendToPipe, Int32 timeout, Boolean& usedCache, Boolean asyncWrite, Boolean inRetry, String methodName)
at Microsoft.Data.SqlClient.SqlCommand.ExecuteNonQuery()
at Microsoft.EntityFrameworkCore.Storage.RelationalCommand.ExecuteNonQuery(RelationalCommandParameterObject parameterObject)
at Microsoft.EntityFrameworkCore.Migrations.MigrationCommand.ExecuteNonQuery(IRelationalConnection connection, IReadOnlyDictionary`2 parameterValues)
at Microsoft.EntityFrameworkCore.Migrations.Internal.MigrationCommandExecutor.ExecuteNonQuery(IEnumerable`1 migrationCommands, IRelationalConnection connection)
at Microsoft.EntityFrameworkCore.Migrations.Internal.Migrator.Migrate(String targetMigration)
at Microsoft.EntityFrameworkCore.Design.Internal.MigrationsOperations.UpdateDatabase(String targetMigration, String contextType)
at Microsoft.EntityFrameworkCore.Design.OperationExecutor.UpdateDatabaseImpl(String targetMigration, String contextType)
at Microsoft.EntityFrameworkCore.Design.OperationExecutor.UpdateDatabase.<>c__DisplayClass0_0.<.ctor>b__0()
at Microsoft.EntityFrameworkCore.Design.OperationExecutor.OperationBase.Execute(Action action)
ClientConnectionId:359e964b-b07a-4130-856e-db417d8e28ec
Error Number:2705,State:4,Class:16
Thanks for your response. Unfortunately, upgrading to 5.1 did not fix the issue.
Following the Github issue you linked, we have disabled entity history, and that works as a temporary workaround. But please let us know if/when there is a more stable solution.