-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
feat: move functions to define repository classes from @loopback/rest-crud to @loopback/repository #4792
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code changes look reasonable to me, but I'm confused about the context of the move (I read #4296). Can you explain it a bit more?
packages/repository/src/__tests__/unit/repositories/define-crud-repository-class.unit.ts
Outdated
Show resolved
Hide resolved
Have you considered preserving backwards compatibility by adding re-export of
+1, can you please @raymondfeng shed more light on your motivations? Personally, I did consider to move Let's discuss. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@raymondfeng thank you for starting this work, I agree it's a good idea to make our repository-class-factories more flexible.
The most important problem I see in this pull request is that since all changes are bundled in a single commit with BREAKING CHANGE
trailer, it will trigger semver-major release of @loopback/repository
and include description of breaking changes in repository's release notes. IMO, that's not desired.
I also find the current proposal as changing too many things at once, in a way that does not make it clear where one change ends and another starts. I see the following changes here:
- Introduction of new factories (
defineCrudRepositoryClass
,defineKeyValueRepositoryClass
) - Reworking the API to be more extensible and support custom repository base classes to some extent
- Reorganization of code, moving the factory function from
@loopback/rest-crud
to@loopback/repository
.
Let's find a way how to organize the patch in such way that each change is isolated and easier to understand.
I am proposing the following plan:
-
Introduce generic repository-class-factory functions in
@loopback/repository
(defineCrudRepositoryClass
,defineKeyValueRepositoryClass
). Make sure they support custom repository base classes both at compile time and at run time. I think this would make for a nice standalone pull request. -
Rework
@loopback/rest-crud
to preserve the API but implement the factory function using the new@loopback/repository
APIs. Perhaps deprecate the exported function? If you feel strongly about removing the factory API from@loopback/rest-crud
completely, then I am fine with that too. However, I don't want to couple the upcoming semver-major release with landing of this pull request, because it would create unwanted pressure on getting this landed ASAP, instead of taking enough time to iterate until we find a good API & implementation.
d1c58e7
to
5ddf752
Compare
@bajtos @nabdelgadir PTAL |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good progress 👏
I see several issues with the TypeScript typings used in the new version. The names used also make it easy for the reader to get confused about what interface/type-alias refers to what. Let's improve these aspects please and make sure we also have tests to verify that the compiler will allow users to call the repository classes in the way we would like them to.
packages/repository/src/__tests__/unit/repositories/define-repository-class.unit.ts
Show resolved
Hide resolved
packages/repository/src/__tests__/unit/repositories/define-repository-class.unit.ts
Outdated
Show resolved
Hide resolved
5ddf752
to
c016550
Compare
@bajtos I believe the latest PR has addressed your comments. PTAL. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Almost there! I have few more minor comments to consider. PTAL below.
packages/repository/src/__tests__/unit/repositories/define-repository-class.unit.ts
Show resolved
Hide resolved
packages/repository/src/__tests__/unit/repositories/define-repository-class.unit.ts
Show resolved
Hide resolved
38443b5
to
ab4950a
Compare
@bajtos PTAL. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@raymondfeng I am afraid you still did not addressed my comments asking for support of custom repository methods.
PTAL at #4949, it has three commits with suggestions how to improve your PR.
-
I think the first can be applied as-is.
-
I am not sure if the second commit is an improvement or not. When applied, it helped me to catch the problem with AddressRepository using
any
as the model type, but further investigation revealed that it was a kind of of a coincidence. OTOH, it can create confusion because it changes some repository-related types to accepttypeof Model
instead ofModel
as the first generic argument. -
The third commit adds tests to verify support for custom repository methods and also fixes the implementation as needed. If you decide to leave the second commit out, then it will need few changes to accommodate that.
packages/repository/src/__tests__/unit/repositories/define-repository-class.unit.ts
Outdated
Show resolved
Hide resolved
packages/repository/src/__tests__/unit/repositories/define-repository-class.unit.ts
Outdated
Show resolved
Hide resolved
@raymondfeng , @bajtos |
ab4950a
to
3ec19d0
Compare
3ec19d0
to
401a81c
Compare
I rebased the PR on top of the latest master and merged in changes from #4949. The rebase was a bit tricky, I ended up re-creating both commits from scratch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@raymondfeng PTAL, I merged the changes proposed in #4949.
I find the new version pretty rad, I think the only remaining point to discuss is a better name for NamedRepositoryClass
.
Thoughts?
* @typeParam M - Model class | ||
* @typeParam R - Repository class/interface | ||
*/ | ||
export interface NamedRepositoryClass< |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The name of this class is a discussion point we haven't resolved yet. See #4949 (comment).
Cross-posting my latest comment:
Maybe we should take another angle. My intention is to distinguish between a generic repository class that works for any Model/Entity and a repository class that's already specialized for (bound to) a given Model/Entity.
In that light, perhaps
BoundRepositoryClass
orSpecializedRepositoryClass
would be better names?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe TypedRepositoryClass
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I renamed it to ModelRepositoryClass
. Let's just land it - no need to be perfect.
respositories using code. | ||
(`defineCrudRestController` from `@loopback/rest-crud` and | ||
`defineCrudRepositoryClass` from `@loopback/repository`). These functions will | ||
help you create controllers and repositories using code. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we revert this change since defineCrudRepositoryClass
is still exported by @loopback/rest-crud
? (Same comment applies to other similar doc changes below.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine either way.
9350c5d
to
88cce18
Compare
Introduce `defineRepositoryClass`, a generic variant of `defineCrudRepositoryClass` that can be used for any base repository implementation. Implement two convenience wrappers for creating default CRUD/KeyValue repository classes: - `defineCrudRepositoryClass` - `defineKeyValueRepositoryClass` Co-authored-by: Miroslav Bajtoš <[email protected]>
…repository` Drop our own implementation in favor of the new generic version. Co-authored-by: Miroslav Bajtoš <[email protected]>
88cce18
to
aaf77df
Compare
The PR is inspired by:
defineModelClass
in@loopback/repository
For@loopback/rest-crud
:BREAKING CHANGE:
defineCrudRepositoryClass
is now removed from@loopback/rest-crud
. Please usedefineEntityCrudRepositoryClass
from@loopback/repository
instead.See some context at #4296
Checklist
👉 Read and sign the CLA (Contributor License Agreement) 👈
npm test
passes on your machinepackages/cli
were updatedexamples/*
were updated👉 Check out how to submit a PR 👈