-
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
[RFC WIP] feat(typegoose): add a component for typegoose/mongoose integration #5152
Conversation
Thank you for starting the discussion about adding support for Mongoose-based ORM framework for working with MongoDB! ❤️ 👏 Few high-level comments:
@raymondfeng can you please review? You are the author of #4794 which inspired this work. |
In fact, I did not. I will do so, and commit changes. |
extensions/mongoose/src/__tests__/integration/schemas/Event.schema.ts
Outdated
Show resolved
Hide resolved
extensions/mongoose/src/__tests__/integration/schemas/Event.schema.ts
Outdated
Show resolved
Hide resolved
@mschnee Great initiative. In addition to my comments inline, I would suggest:
|
docs: add more example code to README.md fix: use build-extension to create @loopback/typegoose feat: adds mongoose variant docs: update README files fix: license headers fix: remove mongoose
aa783dc
to
742bf6c
Compare
Done! I'm not entirely sure how I feel about having to pass all the schemas in via configuration. It's not the worst possible pattern- for both the |
We can possibly define an extension point for Mongoose schemas. Then there can be a booter to load such schemas or have app code to explicitly contribute to the extension point. |
…k-next into feat/typegoose-extension
Will this design allow applications to register additional schemas dynamically at runtime, after the application started? |
@mschnee thanks for the PR. Here's my feedback.
|
We just switch the contribution method from CLA to DCO, making your contribution easier in the future. Please sign the commits with DCO by amending your commit messages with
Please refer to this docs page for details. Thanks! |
Inspired by #4794 and by a project I am working with that has a large number of existing Typegoose and Mongoose schemas/models already defined.
Unlike TypeORM, which provides connections that have typed entity managers, mongoose and Typegoose put the Model above the connection, and developers interact with Model objects directly to fetch/query/update documents through the underlying connection.
This is a very rough WIP, and more of a weekend project to start a discussion.
Goals
@inject()
the connection-models you need when you need them, instead ofrequire()
ing them in the global scope, which is common in lots of mongoose/typegoose examples.Example?
TODO
TestTypegooseComponent
is messy, and I'm not sure if it's a good pattern.BindingKey
may be too strict, and too inflexible for some cases where applications may have dynamic connections.application.ts
seems like the wrong place.Background
The Hello World example for mongoose looks like this:
What's hidden under the hood are the connections. You can connect to multiple database hosts.
Even though these two connections refer to the same database, mongoose treats references separately.
Typegoose adds stricter type checking with Typescript to mongoose:
Checklist
👉 Read and sign the CLA (Contributor License Agreement) 👈
npm test
passes on your machinepackages/cli
were updatedexamples/*
were updated