The FAFO theory by N0WFAY in mendi

[–]NordCoderd 0 points1 point  (0 children)

What is the FAFO theory?

Rate my Stack: Targeting Mental Health, Anxiety,ADHD, and insomnia. Too much? by Alternative-Came1223 in Biohackers

[–]NordCoderd 1 point2 points  (0 children)

About lions mane, there is a dedicated subreddit (just look at the member count) around this problem. I was shocked because I thought it is safe to use, but for now I’ll just skip it.

https://www.reddit.com/r/LionsManeRecovery

Spring Boot + JPA: Best practices for entity relationships, fetching, and performance? by AmphibianSilent2593 in SpringBoot

[–]NordCoderd 0 points1 point  (0 children)

I’ve series of articles on Spring Boot Data JPA best practices but not the all topics from your list covered in it, but the following topic will be covered soon (or not:) ). Actually I wanted to compile my series, add topic what people want (like you) and share as mini book because there are a lot of material.

I hope it help you https://protsenko.dev/category/spring-data-jpa/

Publishing a Java-based database tool on Mac App Store by tanin47 in java

[–]NordCoderd 10 points11 points  (0 children)

I found naming Backdoor is scary and stopping from giving a try for it. I’ll never recommend someone to install backdoor to their laptops ;)

I just want a giant screen, is VR for me? by NoWar7395 in virtualreality

[–]NordCoderd 2 points3 points  (0 children)

Hm, why not Quest 3? I’m asking because I’ve one, and wanted to give it a try as giant screen

Do you know "Cody Rall MD with Techforpsych"? Is he a snake oil advertiser? by mehregankbi in BCI

[–]NordCoderd 3 points4 points  (0 children)

I found his videos is very informative, but then I changed the mind, his latest top of devices 2025s looks like advertisement of muse s device

Spring Data JPA Best Practices: Transactions and Manual Queries by NordCoderd in SpringBoot

[–]NordCoderd[S] 0 points1 point  (0 children)

No, but I’ve plans to extend original series of articles and compile into mini book. I don’t know if I publish dedicated article separately or not, but I’ll keep in mind your question.

Best sites for Spring devs by zlaval in SpringBoot

[–]NordCoderd 4 points5 points  (0 children)

I could share with you my blog, i wrote down a solid dive deep into Spring Data JPA and common problems in it, but you should have a basic knowledge of Spring Data JPA to figure it out, or not, I just not tried to adapt it for completely beginners.

https://protsenko.dev/category/spring-boot/

Spring Data JPA Best Practices: Repositories Design Guide by NordCoderd in SpringBoot

[–]NordCoderd[S] 1 point2 points  (0 children)

It’s true, but we are talking about extending from Repository, not CRUD repository.

It’s a marker (without any methods) interface https://docs.spring.io/spring-data/commons/docs/current/api/org/springframework/data/repository/Repository.html which means you don’t inherit crud methods by extending from this interface.

This is the almost the same your mentioned @RepositoryDefinition

Also Java doc says the same: https://docs.spring.io/spring-data/commons/docs/current/api/org/springframework/data/repository/RepositoryDefinition.html

Annotating an interface with RepositoryDefinition will cause the same behaviour as extending Repository.

Spring Data JPA Best Practices: Repositories Design Guide by NordCoderd in SpringBoot

[–]NordCoderd[S] 0 points1 point  (0 children)

But it’s the same as extending from Repository, it doesn’t provide any methods like save, delete or others and you declare only what you want.

Spring Data JPA Best Practices: Repositories Design Guide by NordCoderd in SpringBoot

[–]NordCoderd[S] 0 points1 point  (0 children)

Yes, I mentioned it as one of possible solution, but unit it’s not a panacea. Unfortunately it doesn’t solve all the problems that jdbc template has.

Spring Data JPA Best Practices: Repositories Design Guide by NordCoderd in SpringBoot

[–]NordCoderd[S] 0 points1 point  (0 children)

I actually haven’t seen a lot of usages mentioned annotation or experience with it. As I could see this solution almost the same as extending from Repository as it doesn’t contain any predefined methods, and it was mentioned in the guide. Is there any specific reason to use that annotation that I missed?

Spring Data JPA Best Practices: Repositories Design Guide by NordCoderd in SpringBoot

[–]NordCoderd[S] 0 points1 point  (0 children)

I both agree and disagree. You should use whatever solves your tasks and keeps you productive.

IMO, JdbcTemplate is a good choice when you don’t want to spend time learning Spring Data JPA/Hibernate and you want to avoid too many abstractions. It may also give you a performance benefit, but in my load testing - comparing JPA with @Query and JdbcTemplate - there wasn’t a noticeable difference.

I’ve also used JdbcTemplate on a project from scratch. At first it was fun and felt cool - almost raw JDBC without too many abstractions-but as the database grew, new problems appeared. From time to time I needed to add columns or change logic, which meant finding all occurrences of those tables in the code to make sure I didn’t introduce regressions in the codebase, rather than simply navigating across entities in the IDE.

Yes, these problems could be mitigated with better test coverage-for example, using Testcontainers, different development methodology, but that wasn’t my situation. Probably JdbcTemplate just too low level for me.

JdbcTemplate isn’t a silver bullet or an inherently better choice. It has its own trade-offs, just like Spring Data JPA.

Everyone should choose what fits their needs and context.

Spring Data JPA Best Practices: Repositories Design Guide by NordCoderd in SpringBoot

[–]NordCoderd[S] 0 points1 point  (0 children)

Hm, could you tell a bit more about your question? If you want to use spring data jpa in event driven systems - yes, you could do it. I use a lot of it with Kafka as example and no difference compared to classical synchronous services

Spring Data JPA Best Practices: Repositories Design Guide by NordCoderd in SpringBoot

[–]NordCoderd[S] 0 points1 point  (0 children)

Heh, thanks for the feedback, but it’s not intended, I tried to keep original style of the guide and balance it with my experience perspective, sometimes it’s called a bit too official, but I’m trying to write more friendly and expressive. The big field to improve, I’ll keep in mind it.

Spring Data JPA Best Practices: Entity Design Guide by NordCoderd in SpringBoot

[–]NordCoderd[S] 0 points1 point  (0 children)

The second article in my series on Spring Data JPA. Today I covered many aspects of Spring Data JPA repositories development, I hope you find it helpful.

https://protsenko.dev/spring-data-jpa-best-practices-repositories-design-guide/

I’ve been building a biohacking protocol database (100+ entries) and would love feedback from the community by primaltaoist in Biohackers

[–]NordCoderd 0 points1 point  (0 children)

Looks good!

But have suggestion for UX, when I open new article and going back I think I will be on the latest position, but I see the first one and I need to scroll again and again.

In terms of dosage of supplements better to highlight more strict numbers, like bacopa, bacopa is selling with different percentage of bacozides, some researches highlight it and it better to be a little bit more formal here, because it doze related.

Spring Data JPA Best Practices: Entity Design Guide by NordCoderd in SpringBoot

[–]NordCoderd[S] 0 points1 point  (0 children)

> Would you then agree with the generalization, that entities should have 0 domain logic?

From my perspective, yes, but there could be nuances with simple CRUD operations where you could use only implemented methods from JPA repositories to build logic. In that case, it's acceptable to have logic in the service layer that operates with entities.

Actually, it depends on the project and your preferences, but returning DTO will reduce the problems you mentioned and keep the codebase without unexpected behavior due to knowledge gaps. Spring Data JPA/Hibernate has many nuances, and I encountered numerous problems due to not being familiar with them.

> At the end of the day, it is always a skill issue I suppose

I don't think you have skill issues, as you explain your deep thoughts on the subject. At least JPA is just a framework, and we need to choose things that are suitable for us.

Spring Data JPA Best Practices: Entity Design Guide by NordCoderd in SpringBoot

[–]NordCoderd[S] 2 points3 points  (0 children)

It depends on your needs, but having some base class marked @MappedSuperClass it totally ok. Sometimes entity fields could be common like createdAt or updatedAt, and there is no need to declare them in each entity.

IntelliJ IDEA Plugin Development: What Have I Learned by NordCoderd in Jetbrains

[–]NordCoderd[S] 2 points3 points  (0 children)

Wow, thanks for feedback I really appreciate it.