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

Relation refactoring: Split Repository interface into different interfaces #1356

Closed
3 tasks
dhmlau opened this issue May 24, 2018 · 6 comments
Closed
3 tasks

Comments

@dhmlau
Copy link
Member

dhmlau commented May 24, 2018

Description / Steps to reproduce / Feature proposal

See #1194 (comment) for background. This tasks aims to break up the Repository interface into different interfaces based on the persistence function type and refactor the repository interfaces which extend from it to use those interfaces via a Mixin.

Acceptance Criteria

  • Split Repository interface into different interfaces based on the persistence function type i.e. LookupRepository interface to have all the Retrieval methods, WriteRepository (I'm sure there is a better name), would have the create methodsMutationRepository might have the update and related methods (this might fall under the previous one), and DestroyRepository for deletes. A good list from @raymondfeng:
  1. QueryRepository - read-based operations (find, findOne, count, ...)
  2. MutationRepository - write-based operations (create, update, delete, ...)
  3. CrudRepository (QueryRepository + MutationRepository)
  4. EntityRepository (CrudRepository + findById, updateById, deleteById, ...)
  • Explore the use of a Mixin for a smart way of sharing the implementation bits from the different repositories (for e.g. how can HasManyEntityCrudRepository inherit the needed CRUD methods from the interfaces mentioned above?).

  • tests / docs

@jannyHou
Copy link
Contributor

jannyHou commented Jun 7, 2018

from @raymondfeng
different ways to split the repository interfaces:
query vs mutation
PK based vs KV based

follow-up discussion:
know the nature of a method at run-time
run-time access control for certain methods(e.g. mutation methods)

We need more time to discuss. Revisit it next time.

@jannyHou
Copy link
Contributor

@strongloop/sq-lb-apex @hacksparrow @raymondfeng @bajtos Any updates on this story?

@b-admike
Copy link
Contributor

@jannyHou Sorry, I need to work with @raymondfeng to update the acceptance criteria. I'll have it ready for our next estimation meeting.

@raymondfeng
Copy link
Contributor

Here are some candidates I see:

  1. QueryRepository - read-based operations (find, findOne, count, ...)
  2. MutationRepository - write-based operations (create, update, delete, ...)
  3. CrudRepository (QueryRepository + MutationRepository)
  4. EntityRepository (CrudRepository + findById, updateById, deleteById, ...)

@stale
Copy link

stale bot commented Oct 28, 2019

This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository. This issue will be closed within 30 days of being stale.

@stale stale bot added the stale label Oct 28, 2019
@stale
Copy link

stale bot commented Nov 27, 2019

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.

@stale stale bot closed this as completed Nov 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants