Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enabling multiple data providers #57

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

verbedr
Copy link
Contributor

@verbedr verbedr commented Mar 18, 2022

  • added an interface with factory
  • included ef core provider
  • included json provider
  • did some code reorganisation/move/rename

This is a POC/idea to implement the #4 issue. I know this is a big code change at once, my apologies for this. If some changes conflicts with the initial idea or concept of this project, again my apologies.

I hope this can kickstart a discussion on how to implement it.

PS there are a lot of parts in the code that can be improved or made more robust.

@verbedr verbedr force-pushed the feature/multi-repo branch 2 times, most recently from 2c0d002 to 81d72b3 Compare March 19, 2022 23:36
@csharpfritz
Copy link
Owner

This is a huge change, removes a bunch of public-facing objects which will break compatibility.

We would prefer a more focused pull-request that delivers just one feature from the issues list. Some of these changes may be valuable, but its too many items changing all at once

@verbedr
Copy link
Contributor Author

verbedr commented Mar 20, 2022

No problem, if there is something I can change, so it is more tangible, let me know. It was a sort of concept or set of ideas to solve the multiple repository problem. Perhaps there is something salvable.

@verbedr verbedr force-pushed the feature/multi-repo branch 2 times, most recently from 5e4cac5 to ffb78e0 Compare March 22, 2022 21:30
Dries Verbeke added 9 commits July 22, 2022 01:53
Using a central test fixture to setup the tests around
the configuraiton builder so we do not duplicate the creation
of the setup mock.
The instiant apis' config class only holds one property. Instead of
using a class to hold one property as a dto, pass only that property.
Applying the yagni (yet) principle.
Renaming the InstantAPIsConfigBuilder to the
InstantAPIsBuilder as there is no need to make this distinction
and the builder represent beter of what it is doing. Also
renamed the file to match the class
The build produced a couple warnings around null references
and had some bad project references. In order not to hide real
warnings that need to resolve. The idea is to make sure there
are zero warnings
To be more inline with other library setups we rename the
ServiceOptions to plain Options. There is no specific need
for ServiceOptions in a plugin.
- Renaming existing generic types to convention Txxx
- Add generic types for set, entity, key
- Use an expression to identity the dbcontext.set. This ensure
  better/correct configuration
- added an interface with factory
- included ef core provider
- included json provider
- update the test programs to utilize the repository approach
- implemented an update
- insert should take max of the key + 1, instead of just counting
- remove unused constructor prarameter
@verbedr verbedr force-pushed the feature/multi-repo branch from ffb78e0 to 625abfc Compare July 22, 2022 01:48
@verbedr
Copy link
Contributor Author

verbedr commented Jul 22, 2022

So I tried to break up the single commit in different steps to make it more understandable and rebased it from the new main branch. If there is anything else I can do to make it more acceptable, let me know.

@csharpfritz
Copy link
Owner

csharpfritz commented Oct 11, 2022 via email

@verbedr
Copy link
Contributor Author

verbedr commented Oct 11, 2022

Hi Jeff,
thanks for the response. I do understand the problem, therefore I had broken up my single big commit in little commits. The thing I'm a bit lost with is how to handle those small steps.

For example, the first commit is using a single fixture to set up and teardown similar unit tests. As it isn't a real issue for the application, I'm reluctant to create an Issue for this. But, should I instead create a single PR with only the first commit and start up a discussion with those changes?

I can do this step by step for every single commit if this would make it more open and allows others to comment or even pitch in different ideas. Let me know if that would be workable for you.

Kr
Dries

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants