Once you create an explicit method in the child class that matches the dynamic accessor method (e.g. getFieldname() ), and that method doesn't exist in the super class, that method becomes the accessor for the package.
For what you're looking to do, I'm not sure inheritance is the best solution. I would suggest mapping ReportCriteria as a many-to-one property, so that your accessor overloads can call it directly. The other option is to ensure that your overload methods exist in the super class.
Jon
[Note: Typo assistance courtesy of iPhone]
> On Feb 4, 2015, at 2:58 PM, Tristan Lee <
trista...@gmail.com> wrote:
>
> Trying my first go at entity inheritance...
>
> I have ReportCriteriaAssigned that extends ReportCriteria. For ease on the eyes, here are gists to the source:
>
> ReportCriteriaAssigned -
https://gist.github.com/tristanlee85/c22a2f379ced2a621e87
> ReportCriteria -
https://gist.github.com/tristanlee85/ce986c199536b38c8508
>
> Between the 2 entities, both have a "fieldname" and "label" property. Idealy, if either of those properties in ReportCriteriaAssigned have a value, I would like to use that. Otherwise, if they are NULL, then I want to use the "fieldname" / "label" property from ReportCriteria since it will always contain a default value.
>
> I created 2 methods getFieldname() and getLabel() which check for the existance of the property and invoke super.get...() if it doesn't exist. However, it appears that the call to super is still referencing the properties of the subclass. It could be that my thought on a superclass for Hibernate has be confused with traditional techniques... thoughts?
>
> --
> You received this message because you are subscribed to the Google Groups "cf-orm-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
cf-orm-dev+...@googlegroups.com.
> To post to this group, send email to
cf-or...@googlegroups.com.
> Visit this group at
http://groups.google.com/group/cf-orm-dev.
> For more options, visit
https://groups.google.com/d/optout.