-
Notifications
You must be signed in to change notification settings - Fork 3k
Adjust the tone of the Panache/Repository guide for JPA and Mongo #5088
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
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed. Thanks for the review!
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.
One error and maybe the sentence about repository can be simplified
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it! Updated.
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.
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. |
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.
Can you have a look at my comments? Thanks!
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is they
?
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.
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. |
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.
+1
|
||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same question :).
@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 |
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. |
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.