|
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 ever 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).
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.
|
