Home » Support » Forum » Request clarification of changes to accessor enhancement policy (non-getter prefix instead of getter suffix) AND annotations

Request clarification of changes to accessor enhancement policy (non-getter prefix instead of getter suffix) AND annotations

#1

In response to the forum posting http://www.objectdb.com/database/forum/994 changes were made to the way enhancement treats getters and setters (property accessors), namely there are no longer enhanced additional getters/setters, because the additional methods now use (since about version 2-6-5) this pattern:

    __odbHidden_[accessor_name]

Instead of this pattern with a suffix (preserving the method as a setter or getter), prior to version 2-6-5:

    [accessor_name]_odbHidden_

Where [accessor_name] typically has a form like getFieldName or  setFieldName.

May I just observe that this change massively tripped me up (because I was using the old hidden getter/setter pattern with reflection for various tasks, including for diagnosing whether enhancement has indeed taken place, leading me to the false conclusion recently during tests with objectdb-2.6.9_02.jar that enhancement had NOT taken place when it had).

I see now that it is included under the download Notes at:

    http://www.objectdb.com/object/db/database/version/2-6-5

    - Renamed internal Enhancer hidden methods to non property method names.

This change is a huge GOTCHA, and should be announced somehow via some special channel (if you have such channel one can subscribe to for announcements on such important changes, please advise).

(One could argue that I am supposed to be checking every change announced in every version under the Notes links in download pages, but in this case I was "stuck" on objectdb-2.6.3_04.jar because of other bugs - since confirmed as such by ObjectDB support - and have "jumped" to objectdb-2.6.9_01.jar and objectdb-2.6.9_02.jar, and missed this change.)

But I see now also that the change is NOT just limited to changing the enhanced method pattern, the policy for annotations has also changed !

Previously, any annotations (including custom annotations unrelated to JPA, of which I make heavy use) were "moved" to the ObjectDB "hidden" getter (or setter). I see now (using reflection tests) that any annotations seem now to "remain" with the original accessor.

Q: Can you please confirm that my analysis is correct, and that now the Annotations are on the getters, which are now as far as the outside world is concerned "untouched" ?

For what it's worth, I prefer the new policy, however this has major consequences for my main web app development (broke it), because I was necessarily using reflection on the old getter-style hidden ObjectDB methods, because they were (for better or worse) the annotated ones. I am now going to have to perform a substantial migration in my main web app because of this change (as a side-effect of that fact that the old enhancement approach, which "moved" the annotations, essentially broke the JPA API, one reason I prefer the new non-accessor hidden method approach).

Luckily, most of the cases I can handle as encapsulated policy changes without too much fiddly coding, but it's still a major inconvenience.

As far as I can tell, this change to the annotations policy was not announced under the Download notes for any ObjectDB version.

--- Webel IT Australia, "The Elements of the Web", Specialists in model-based UML, SysML, Enterprise Java, XML, and Drupal CMS web engineering. Dr Darren Kelly, BSc, PhD, https://www.webel.com.au
#2

I see now that this was (in part) addressed at a remark from ObjectDB support at one of my own issue reports.

"Starting build 2.6.4_03 Enhancer generated hidden methods will have a __odbHidden_ prefix again (as was until version 2.2.6 and fixing this issue). This is required due to another issue.

However, the issue described here is not expected to happen again, since the annotations are now moved from the Enhancer generated hidden methods to the property get/set methods. If it does happen again then please report."

It seems the policy for whether __odbHidden was used as a prefix or suffix (and treatment of annotations) was changed back and forth in various versions, which versions I was unable to ever use because of other bugs, hence my noticing this in the reflection aspects of my applications only now.

For example, that issue I link to above initially concerned 2.2.6. I just tested using reflection objectdb-2.6.3_04.jar and it definitely used the old policy.

The main point of this posting is to emphasise that annotations are part of the API, and may include custom annotations. The original strategy of "moving" the annotations from the true accessors to the hidden objectdb ones was always fragile, and has caused problems.

I consider this answered, but welcome any feedback.

--- Webel IT Australia, "The Elements of the Web", Specialists in model-based UML, SysML, Enterprise Java, XML, and Drupal CMS web engineering. Dr Darren Kelly, BSc, PhD, https://www.webel.com.au
#3

Accessing and using directly Enhancer hidden methods is risky and should be avoided (or at least checked carefully when switching versions), as it is not part of the ObjectDB / JPA API and may change with no notice.

> The original strategy of "moving" the annotations from the true accessors to the hidden objectdb ones was always fragile, and has caused problems.

Agreed. But note that ObjectDB never really moved annotations to the hidden methods but actually changed the names of the original property methods (to hidden names) and then added new public methods with the original names. The original code and the original annotations remained unchanged together and only the method names changed. Now ObjectDB actually moves annotations to the new public method. This is probably the right thing, although we may find in the future that some specific annotations may have to remain with the original code, so this could still break things and require additional adjustment for specific annotations in the future.

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)
#4

Thanks for your detailed reply. You wrote:

"Accessing and using directly Enhancer hidden methods is risky and should be avoided
(or at least checked carefully when switching versions), as it is not part of
the ObjectDB / JPA API and may change with no notice."

It was previously necessary and unavoidable to at least interrogate the enhanced getter versions if one wished to leverage custom annotations on the getters (just one reason the new system with the annotations on the non-hidden getters is better).

You wrote:

"[previously] The original code and the original annotations remained unchanged together and only the method names changed. Now ObjectDB actually moves annotations to the new public method."

At one stage, some years ago when I was using EclipseLink, I was using the setters to perform additional tasks such as additional validations and some operations one might consider "side-effects". I found on switching to ObjectDB this did not work and stopped the practice completely.

 

 

--- Webel IT Australia, "The Elements of the Web", Specialists in model-based UML, SysML, Enterprise Java, XML, and Drupal CMS web engineering. Dr Darren Kelly, BSc, PhD, https://www.webel.com.au

Post Reply

To post a reply and/or subscribe to update notifications - please login