Adjust the tone of the Panache/Repository guide for JPA and Mongo #5088
Conversation
| So if Repositories are your thing, you can keep doing them. Even with repositories, you can keep your entities as | ||
| subclasses of `PanacheMongoEntity` in order to get the ID and public fields working, but you can even skip that and | ||
| go back to specifying your ID and using getters and setters if that's your thing. We're not judging. | ||
| subclasses of `PanacheEntity` in order to get the ID and public fields working, but you can even skip that and |
There was a problem hiding this comment.
| subclasses of `PanacheEntity` in order to get the ID and public fields working, but you can even skip that and | |
| subclasses of `PanacheMongoEntity ` in order to get the ID and public fields working, but you can even skip that and |
There was a problem hiding this comment.
Fixed. Thanks for the review!
| So if Repositories are your thing, you can keep doing them. Even with repositories, you can keep your entities as | ||
| subclasses of `PanacheMongoEntity` in order to get the ID and public fields working, but you can even skip that and | ||
| go back to specifying your ID and using getters and setters if that's your thing. We're not judging. | ||
| subclasses of `PanacheEntity` in order to get the ID and public fields working, but you can even skip that and |
There was a problem hiding this comment.
subclasses of PanacheMongoEntity
| Repositories can be amazing or evil, depending on the complexity of your needs. When they work, | ||
| they can save you from writing lots of boilerplate and error-prone JPA/SQL/Criteria queries, | ||
| but when they fail you need a way to drop back to more traditional methods... Don't worry, | ||
| Panache and Quarkus have you covered either way. |
There was a problem hiding this comment.
The first sentence feels a bit long and still has some judgment. Maybe going straigth to the point should be bettre.
Repository is a very popular design and can be very accurate for some use case, Panache and Quarkus have you covered ...
There was a problem hiding this comment.
I like it! Updated.
There was a problem hiding this comment.
Still thinking that the following sentence is not needed:
but when you need to support a complex use case you can revert
to more traditional methods...
And the Don't worry seems to miss some introduction
If you need them, don't worry ...
|
@InfoSec812 Thanks for the PR! One thing we usually ask contributors to do is squash so a single commit (or into more logical commits if it makes sense) before merging in order to get rid of commits addressing review comments and such. |
| Look, we get it: you have a love/hate relationship with DAOs/Repositories but you can't live without them. We don't judge, we | ||
| know life is tough and we've got you covered. | ||
| Repository is a very popular pattern and can be very accurate for some use case, depending on | ||
| the complexity of your needs. When your use case fits, they can save you from writing lots of boilerplate |
There was a problem hiding this comment.
Reading from the comments, I think the first sentence was modified and the second sentence was not and is definitely not accurate anymore.
| So if Repositories are your thing, you can keep doing them. Even with repositories, you can keep your entities as | ||
| subclasses of `PanacheEntity` in order to get the ID and public fields working, but you can even skip that and | ||
| go back to specifying your ID and using getters and setters if that's your thing. We're not judging. | ||
| go back to specifying your ID and using getters and setters if that's your thing. Use what works for you. |
|
|
||
| Look, we get it: you have a love/hate relationship with DAOs/Repositories but you can't live without them. We don't judge, we know life is tough and we've got you covered. | ||
| Repository is a very popular pattern and can be very accurate for some use case, depending on | ||
| the complexity of your needs. When your use case fits, they can save you from writing lots of boilerplate |
machi1990
added
the
triage/needs-rebase
@geoand I've never really developed a habit of using rebase/squash because I prefer the added details in my commit history. Is there a command which you recommend to make it simple? |
|
@InfoSec812 I usually use IntelliJ's build in UI which makes things super easy. Otherwise git's interactive rebase (as explained here for example) is what I occasionally use |
gsmet
force-pushed
the
Issue_326-_-Adopt_a_different_tone_for_Panache_repository_guide
branch
from
3d11dea to
6855891
Compare
|
I made a few additional adjustments and rebased. I think it's good to go now but will wait for CI. |
gsmet
added
triage/waiting-for-ci
6 participants
Resolves quarkusio/quarkusio.github.io#326
The verbiage in the Repository section of the Panache guide, while explicitly stating "we're not judging", comes across as judgemental/condescending to some people. This is a minor adjustment to the tone of the language used so it can appeal to a broader audience.