Activities of "eggersa"

Thank you. That seems to work for me ;). We will probably update to the latest version with the next big feature request. But that really depends on our client. Lets hope is willing to pay.

After a while of debugging I found the issue that was in fact already introduced with 0.9.0.0 as far as I'm concerned.

In 0.8.4 the Delete method in the EfRepositoryBaseOfTEntityAndTPrimaryKey is implemented like this:

public override void Delete(TEntity entity)
        {
            AttachIfNot(entity);

            if (entity is ISoftDelete)
            {
                (entity as ISoftDelete).IsDeleted = true;
            }
            else
            {
                Table.Remove(entity);
            }
        }

However, in the later version the method was for some reason changed to:

public override void Delete(TEntity entity)
        {
            AttachIfNot(entity);
            Table.Remove(entity);
        }

The Remove method of Table (DbSet) internally clears all foreign keys including my Owner property (foreign key) which is marked as required. However, the SoftDelete logic later on modifies the entity and prevents its actual deletion which of course causes a validation and the results in a validation exception.

Is there any chance to workaround this issue?

Please do not take any offense on the following (I do a lot of erros myself and I love your framework anyway), but so far with every update was a new bug introduced that caused painful conversations with our client. Therefore I cannot afford another update.

0.8.4 -> 0.9.0 Bug and the Delete bug 0.9.0 -> 0.9.1.1 Bug

Hello

Thank you imscagdas for your answer. Actually, just deleting the database entry is not enough. You have also to clear the cache with wich I had some issues. Later on I found out how to get and clear the cache. It would be nice to have some Invalidate() function on the cache to make life easier in those situations.

Setting the setting value to the default value in order to delete the setting value from database and cache seems somewhat intransparent and implementation specific. The ISettingManager interface does not specify such behaviour.

Hi.

Turned out it was a bug in the framework that was addressed in the later version 0.9.3. After I did update to this version the problem was solved.

The value is set to RemoteOnly:

<customErrors mode="RemoteOnly">
      <error statusCode="404" redirect="~/Error/E404" />
    </customErrors>

Edit:

I just retestet the application and now it works. I probably had set mode="Off" when I last tested the application. However, I am wondering what exactly is the relation between the customErrors mode and this behavior?

Thank you for your answer. This seems helpful. However, when we bought AspNet Zero, the actual version was 0.8.4. Would you mind to post that specific piece of code from AspNet Zero 1.11?

Hi ismcagdas

Thank you for your fast reply. As is often the case, I just found out the answer myself after publicily asking :oops:. I didn't notice that the WebUrlService is used in order to create the redirect url with the token (so it pointed to the application on my local machine which of course did not know about that token and caused the null exception. I thought that is some remote debugging magic).

However, this raises the question why not simply use the Url property from the HttpRequest object instead of configuring the base url by hand?

Thank you for the answers. I prefer the way with the event bus since it seems business related and I think we both agree that business rules have no "business" in the orm layer. However, inside the HandleEvent method it seems difficult to get the original object:

public class ShootingStatisticsHandler : IEventHandler<EntityUpdatingEventData<Shooting>>, ITransientDependency
    {
        private readonly IRepository<Shooting> shootingRepository;

        public ShootingStatisticsHandler(IRepository<Shooting> shootingRepository)
        {
            this.shootingRepository = shootingRepository;
        }

        public async void HandleEvent(EntityUpdatingEventData<Shooting> eventData)
        {
            Shooting original = await shootingRepository.FirstOrDefaultAsync(eventData.Entity.Id);
            // ...
        }
    }

And the update method in the application layer looks like this:

public async Task UpdateShooting(ShootingEditDto input)
        {
            var shooting = await shootingRepository.FirstOrDefaultAsync(input.Id.Value);
            input.MapTo(shooting);
        }

For some reason, the repository in the event handler returns the already changed object. Is there some caching going on behind I am not aware about?

Hello ismcagdas

Thank you for your answer.

Since I am not using the Layout 4, but Layout 3 I cannot describe the steps. However, with your answer I will be able to investigate the problem myself ;).

Found it myself:

Create a new folder in the <MyProjectName>.Core Project e.g. GeoMapService and then create the appropriate IGeoMapService interface within that folder and a concrete implementation BingGeoMapService.