Skip to content
This repository was archived by the owner on Aug 18, 2021. It is now read-only.
This repository was archived by the owner on Aug 18, 2021. It is now read-only.

SetMediaStorage approach causes unexpected behavior. #73

Open
@bruno-brant

Description

@bruno-brant

Update:

After taking a deep dive into AzureBlob, I've realized that there's a much worse issue at play here. SetMediaStorage is called by AzureBlob to set itself as the media storage for CosmosDb:

https://github.com/Avanade/Liquid-Application-Framework/blob/ac834f46809cd445dda8783ff616ea4ae7af6b33/src/Liquid.OnAzure/Storages/AzureBlob.cs#L62-L65

The caveat is the if instruction. This means that if the Repository is still null, for some reason, then AzureBlob isn't set as the media storage. However, if later on the repository is set, it will not detect that a MediaStorage was set and will use it's default behavior.

This means that the order of initialization may affect this code - calling Workbench.Use... for MediaStorage before calling it for Repository will lead to this unexpected behavior.

This has to be escalated to a bug, since this may bite our users in the a**.

Old issue:

For good or evil, Liquid is based on a service locator pattern (see #39). There's, however, a method on a base class, ILightRepository, that sets a dependant service to the repository implementation:

https://github.com/Avanade/Liquid-Application-Framework/blob/1f805007f58b73ae09067bc56f863ae0fa702224/src/Liquid.Base/Interfaces/Repository/ILightRepository.cs#L18

My guess is that this is a mistake. Repositories should be using WorkBench to obtain a copy of the ILightMediaStorage to use.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingcomplexity:lowThe complexity of the issue is lowsize:largeThe size of the issue is large

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions