3 ms·

They made some concrete criticism based on their experience (hard to maintain, complex annotations, etc), but you in turn dismissed those with "you didn't get"

They made some concrete criticism based on their experience (hard to maintain, complex annotations, etc), but you in turn dismissed those with "you didn't get" and some borderline name-calling. Which bit they didn't get?

eitland 6y ago
doctor_eval wrote: >> You get to throw away all the semantics built into the database structure, including knowledge about indexes, I wrote: > suggests you either don't know JPA very well or your writing is a bit sloppy. To suggest that JPA means "throw[ing] away all the semantics built into the database structure, including knowledge about indexes" indicates either that the person doesn't know what JPA is about: indexes should be used with JPA for all but the most trivial setups. Same goes for other general database knowledge. You wrote: > They made some concrete criticism based on their experience (hard to maintain, complex annotations, etc), I just pointed out that it was either a misunderstanding or so sloppily written as to create misunderstandings. > but you in turn dismissed those with "you didn't get" and some borderline name-calling. Which bit they didn't get? The bit about JPA not standing in the way of using good database practices. It is not name-calling. I point to the exact words doctor_eval uses. To be polite and also be sure to make room for error on my side I also offer the option of sloppy writing. Sloppy writing happens to all of us and I'll be happy to know if doctor_eval didn't mean it or if I've misread it. If not however it is not smart to use big words to try to trash a super useful tool that save many of us lots of time and often increase quality.
- doctor_eval 6y ago
  I don’t think my point was sloppily written, but perhaps you misunderstood it. JPA is conceptually incapable of automatically utilising the structure of the underlying database (despite the fact that the database structure is actually dynamic), so it makes up for it by requiring you to write these huge entity models which declare - and duplicate - that structure. You effectively “throw away” the database structure because you have to rewrite it in Java/JPA. I mentioned indexes but that’s just a side issue. One consequence of this is that it makes refactoring much harder; I found that Java side of a JPA refactor was way more effort than the underlying SQL refactor, but that really shouldn’t be the case.
  - eitland 6y ago
    I might start to get what you are hinting at. Still the > JPA is conceptually incapable of automatically utilising the structure of the underlying database (despite the fact that the database structure is actually dynamic), so it makes up for it by requiring you to write these huge entity models which declare - and duplicate - that structure. You effectively “throw away” the database structure because you have to rewrite it in Java/JPA. The way you wrote it: "you get to throw away" made it seem like you have to throw away your knowledge. (emphasis mine) What you describe above is easy to read, but is of course not "throwing away" but duplication, which is of course an issue, but a totally different one. > I mentioned indexes but that’s just a side issue. Is indexes an issue with JPA or not? ;-) You (or others) might wonder why I pick at your comment but I am so tired of seing people choosing inferior solutions because people are scaring them away from what would be perfect solutions for them.
    - doctor_eval 6y ago
      It’s fine to pick at my comments, that’s what HN is for! I accept that when I said “you get to throw away...” I was being a bit glib. I meant that we write the DDL, run it, and despite it being stored in the database as structure, that DDL is never used again by JPA and you have to rewrite it in annotations. I thought lack of knowledge about indexes was an issue because I had a use case where the generated SQL was (very) sub optimal and thought it was due to an assumption made by JPA, but someone pointed out that maybe I used a Set instead of a List. I still think that’s stupid (it’s hardly fixing the “impedance mismatch” when which is the very purpose of JPA), but might not be index related. That said, knowledge about indexes does impact the design of handwritten queries and JPA doesn’t have that; JPA queries can be overly complex, and even pathological, so again I think the point holds up. In my defence I was listing a lot of issues. I feel like I could write a book on the problems with JPA but all I had was this tiny box on my phone. In terms of scaring people off, that is definitely my intent. There are lots of great ways to get Java talking to SQL, many linked to in this thread, and IMO the majority of developers would be better off choosing almost any alternative over JPA.
      - 6y ago

eitland 6y ago

doctor_eval wrote: >> You get to throw away all the semantics built into the database structure, including knowledge about indexes, I wrote: > suggests you either don't know JPA very well or your writing is a bit sloppy. To suggest that JPA means "throw[ing] away all the semantics built into the database structure, including knowledge about indexes" indicates either that the person doesn't know what JPA is about: indexes should be used with JPA for all but the most trivial setups. Same goes for other general database knowledge. You wrote: > They made some concrete criticism based on their experience (hard to maintain, complex annotations, etc), I just pointed out that it was either a misunderstanding or so sloppily written as to create misunderstandings. > but you in turn dismissed those with "you didn't get" and some borderline name-calling. Which bit they didn't get? The bit about JPA not standing in the way of using good database practices. It is not name-calling. I point to the exact words doctor_eval uses. To be polite and also be sure to make room for error on my side I also offer the option of sloppy writing. Sloppy writing happens to all of us and I'll be happy to know if doctor_eval didn't mean it or if I've misread it. If not however it is not smart to use big words to try to trash a super useful tool that save many of us lots of time and often increase quality.

doctor_eval 6y ago
I don’t think my point was sloppily written, but perhaps you misunderstood it. JPA is conceptually incapable of automatically utilising the structure of the underlying database (despite the fact that the database structure is actually dynamic), so it makes up for it by requiring you to write these huge entity models which declare - and duplicate - that structure. You effectively “throw away” the database structure because you have to rewrite it in Java/JPA. I mentioned indexes but that’s just a side issue. One consequence of this is that it makes refactoring much harder; I found that Java side of a JPA refactor was way more effort than the underlying SQL refactor, but that really shouldn’t be the case.
- eitland 6y ago
  I might start to get what you are hinting at. Still the > JPA is conceptually incapable of automatically utilising the structure of the underlying database (despite the fact that the database structure is actually dynamic), so it makes up for it by requiring you to write these huge entity models which declare - and duplicate - that structure. You effectively “throw away” the database structure because you have to rewrite it in Java/JPA. The way you wrote it: "you get to throw away" made it seem like you have to throw away your knowledge. (emphasis mine) What you describe above is easy to read, but is of course not "throwing away" but duplication, which is of course an issue, but a totally different one. > I mentioned indexes but that’s just a side issue. Is indexes an issue with JPA or not? ;-) You (or others) might wonder why I pick at your comment but I am so tired of seing people choosing inferior solutions because people are scaring them away from what would be perfect solutions for them.
  - doctor_eval 6y ago
    It’s fine to pick at my comments, that’s what HN is for! I accept that when I said “you get to throw away...” I was being a bit glib. I meant that we write the DDL, run it, and despite it being stored in the database as structure, that DDL is never used again by JPA and you have to rewrite it in annotations. I thought lack of knowledge about indexes was an issue because I had a use case where the generated SQL was (very) sub optimal and thought it was due to an assumption made by JPA, but someone pointed out that maybe I used a Set instead of a List. I still think that’s stupid (it’s hardly fixing the “impedance mismatch” when which is the very purpose of JPA), but might not be index related. That said, knowledge about indexes does impact the design of handwritten queries and JPA doesn’t have that; JPA queries can be overly complex, and even pathological, so again I think the point holds up. In my defence I was listing a lot of issues. I feel like I could write a book on the problems with JPA but all I had was this tiny box on my phone. In terms of scaring people off, that is definitely my intent. There are lots of great ways to get Java talking to SQL, many linked to in this thread, and IMO the majority of developers would be better off choosing almost any alternative over JPA.
    - 6y ago