Extend all repositories with overloaded constructor

[danielstarzewski]

Hi,

In ERepositoryBase class there are three constructor overloads. One of them is:

protected EFRepositoryBase(DbConnection existingConnection, IUnitOfWork unitOfWork = null, IInterceptor[] interceptors = null)
            : base(existingConnection, false)
        {
            _unitOfWork = unitOfWork;
            _interceptors = interceptors;

            Configuration.LazyLoadingEnabled = false;
}

This constructor is not used by classes inheriting ERepositoryBase. May I ask to add this constructor (as public) to derived repositories? In modules and platform.

[tatarincev]

Of course! But only if you write for what? :)

[danielstarzewski]

@tatarincev Sure :) There is a library called Effort for testing Entity Framework. Library allows to test with 'in memory' EF context. It's useful for integration testing. I saw in the platform solution that you have used LocalDB for that but I would like to avoid it.
To run the 'in memory' repository I need to have a constructor which takes DBConnection. This is why I am requesting this. But if you have any other ideas how to handle that it would also be great ;)

[tatarincev]

Well, no problem, I'll do it public. But as a workaround, you can define your own types of derived repositories with ctor's accepting DBConnection as a parameter.

[tatarincev]

So I'm little hurried, I can't do this ctor's as public, because it won't help, any way you must to define new ctor's in derived repositories to allow passing DBConnection

[danielstarzewski]

If I have a repository called MyRepository and it derives from ERepositoryBase that's not a problem I can do everything I want. But if I want to include in my tests PlatformRepository I don't have a public constructor which takes DBConnection. Even if I create PlatformRepositoryWrapper of some kind that derives from PlatformRepository I also can't call constructor that takes DBConnection.
Acctually, as I think of it, it would be enough to create constructor that takes DBConnection as protected. It doesn't have to be public

[tatarincev]

I got it. At first, I misunderstood you. But there a lot of modules which need to be changed!

[danielstarzewski]

@tatarincev yes there is a couple of them :) Thank you in advance.

[tatarincev]

If you prepare PR for the repositories that are most important to you, it will be the fastest, then our team will do it. :)

[danielstarzewski]

From my perspective Customer, Catalog, Order and Platform are crucial. The rest is not very important to me but to be consistent probably all modules should be updated eventually.

[danielstarzewski]

So the most important for me are:
MemberRepositoryBase
OrderRepositoryImpl
PlatformRepository
CatalogRepositoryImpl
CustomerRepositoryImpl

[danielstarzewski]

O sorry I didn't see your comment above. Ok I will do PR.

[tatarincev]

It would be wonderful! Thanks

[danielstarzewski]

@tatarincev I noticed you released my PR for the platform a couple of days ago. Thank you for that! That is a great improvement for my tests. Do you know when can I expect the rest of PRs to be released for each module?

[tatarincev]

I've merged all your PRs (about this changes) in the other modules, but there are some not completed changes, they releases have a bit delayed, but they will certainly be soon

[tatarincev]

Released https://github.com/VirtoCommerce/vc-module-customer/releases/tag/v2.14.12