I never intended for you to misunderstand my incredulity, as you likely very accurately called it, for how long it took to fix this. I'm a committer on several open source projects and a contributor to even more. I'm well aware about how long it can take to fix a bug in open source, and it was _not_ what I was upset about.
My frustration derived from the fact that this issue had gone five months without _acknowledgement_. Not a single person had responded with "thanks for the report, we'll look into it as soon as we can" or anything like that. I have _never_ had that experience with an open source project. _Ever_. Taking five months to fix I can understand. Taking five months to get someone to even say anything is what I take issue with.
If five months ago someone had said, "Thanks. It might take us a while to look into this," I would have very quickly responded with, "If you can give me some direction on where to look I'll see if I can take care of it." But, even with regular comments on this issue from me and others continuously keeping it on the feed on the Jira dashboard, nobody said a peep. Unfortunately I couldn't just dive in because I'm in the middle of writing a JavaEE/Spring/JPA/Hibernate/Security book and contributing has been at the bottom of my list lately. I only spent the last WEEK that I spent working on this because it started blocking progress on my book and I couldn't proceed anymore. I was very blindly working on a code base that, I must say, is one of the most confusing code bases I have ever seen in 10 years of working with Java.
And, unfortunately, it was not as simple as a one-liner. In addition to building the {{JavaTypeDescriptor}} based on the {{databaseColumnType}}, I also had to fix issues with the following:
# The {{JavaTypeDescriptor}} for {{Serializable}} matching before other, more-specific descriptors.
# The code in the descriptor registry having a reversed {{isAssignableFrom}} invocation.
# The code calling things like {{getComparator}}, {{extractHashCode}}, {{areEqual}}, {{extractLoggableRepresentation}}, {{toString}}, and {{fromString}} on the {{JavaTypeDescriptor}}. However, since this descriptor is for the database Java type being converted to (for example, {{java.sql.Timestamp}}) instead of the entity attribute being converted from (for example, {{java.time.Instant}}) and the code was passing in the entity attribute, it was always going to fail (you can't cast {{Instant}} to {{Timestamp}} and compare it in the {{JdbcTimestampJavaTypeDescriptor}}). To solve this I had to write an "adapter" {{JavaTypeDescriptor}}.
So, yes, considering all of this that still remained, I would call this "incomplete." Not "completely missing," but "incomplete." The frustrating part isn't that it was incomplete (which I would understand), but that the Hibernate website says otherwise ("only entity graphs remain to be completed"). _If_ this work was tested (which I'll take your word on, if so), it was _only_ tested converting between one type that Hibernate already supported and another type that Hibernate already supported, which is not a common use case for {{AttributeConverters}}. The whole purpose for the {{AttributeConverter}} feature is converting for types that the JPA provider does not already support, something that could not have been tested because I broke in every way imaginable.
|
