Comments (5)
That's right, you have to adjust either a type to accept only the parameters specified in prepareQuery
, or modify Repository to your liking. I'll think how to improve it in the future so it's less confusing.
from domain-driven-hexagon.
- This is just an example to show that you can use TypeOrm repos if you have specific queries that can't be simply queried using
this.findOne()
. In this case either one works, choose any that you like more. prepareQuery
is meant for constructing a query from value objects, since you need to extract values from them. In this example use case we allow querying users only by ID. If you want to allow querying users by, lets say, country, you'd have to add
if (params.address?.country) {
where.country = params.address.country
}
Keep in mind that this is an example implementation and might not be the best solution for all use cases.
from domain-driven-hexagon.
Thank you!
To me it feels like in prepareQuery
I would have to duplicate most of the logic from OrmMapper.toOrmProps
, only that each line will be wrapped in a if (params...) { ... }
clause. Maybe there is a way to re-use the logic from the mapper and use a more abstract if
clause?
from domain-driven-hexagon.
The problem is that mapper requires all (or almost all) fields to be present to save the entity, but in a query all fields are optional. Also a query may have different forms, not just simple ones like discussed here. Here is an example of a prepareQuery
from one of my projects:
...
if (status) {
receiver.status = status;
sender.status = status;
}
if (params?.createdBefore) {
receiver.createdAt = LessThanOrEqual(params.createdBefore);
sender.createdAt = LessThanOrEqual(params.createdBefore);
}
return [sender, receiver];
As you can see this would be impossible to map just by using a mapper, since you can have operators in your query like <= or >=, or you may need to query in a joined tables (like sender
and receiver
in an example above)
from domain-driven-hexagon.
Ah, I see! Now I understand why one would want a more flexible way of preparing queries.
My worry, however, is that this implementation suggests a generality that is not there. The repository exposes a method
findOne(params: QueryParams<EntityProps>)
where
type QueryParams<EntityProps> = DeepPartial<BaseEntityProps & EntityProps>
To anyone who has not studied prepareQuery
in detail, this looks like a method that allows one to search the repository using arbitrary combinations of entity properties.
But when I call, say, UserRepository.findOne({ country: 'Germany' })
then the country param will be silently deleted and the result will be the same as if I had called UserRepository.findOne({ })
. That could lead to nasty bugs.
My "solution" was to remove the find...
methods (except for findById
, which works the same for every entity) from TypeormRepositoryBase
and resort to custom implementations in each repository, in the spirit of UserRepository.findOneByCountry(country: string)
.
from domain-driven-hexagon.
Related Issues (20)
- `StructuredClone()` function converts entity object into plain object, causing `undefined` properties when calling getters HOT 2
- @slonik/migrator is not compatible with slonik 30+ HOT 9
- InternalServerErrorException has incorrect documentation HOT 1
- FindUsersQuery should map data to response in order to avoid leaks HOT 1
- Why are ports defined in infrastructure layer? HOT 2
- Intermittent test failure for create-user HOT 7
- Clarification on the Practical Usage of Domain Services in DDD
- typeof id is undefined HOT 4
- execute start:dev throws error HOT 6
- Implement and add examples for Adapters and Providers from Infrastructure folder? HOT 6
- Enable GitHub discussions ? HOT 1
- Correct approach for different types of concept? HOT 1
- UnitOfWork creating many QueryRunners and not release them HOT 4
- Types are incorrect for value object's unpack method
- Dependency Inversion in new version HOT 1
- Queries using repositories HOT 1
- Query handler breaking the dependency rule? HOT 4
- Authentication module HOT 1
- Resolver returning type HOT 1
- resolver return HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from domain-driven-hexagon.