No, it's a bit more complicated. The template is one portion of the
fix, but even if the entity is marked abstract (in both the mapping
and the java class), cayenne will try to instantiate it in the
aforementioned query on superclass case. So a complete solution will
require that case to resolve and instantiate the subclass types,
rather than attempting to instantiate the superclass type.
Robert
On Apr 23, 2009, at 4/238:53 PM , Aristedes Maniatis wrote:
>
> On 24/04/2009, at 9:53 AM, Robert Zeigler wrote:
>
>> I expected the Entry subclass of _Entry, and superclass of the
>> other two concrete classes to be abstract. Instead, only the
>> cayenne-"managed" superclass was abstract.
>> It seems like there's very little point to that: nobody is going to
>> try to directly instantiate _Entry, anyway. And I can't put
>> abstract methods that subclasses should implement into _Entry,
>> since they'll be lost on class regeneration. I guess it's a matter
>> of expectations: by checking "isabstract", I expect cayenne to
>> treat that object entity as abstract... and not try to instantiate
>> it. :)
>
> Is this fix as simple as changing the DOtemplate for the subclass?
> Now I understand your point and I think you are right that it is
> broken, but the fix should be one line in the template.
>
> To some degree it might make sense for the _Entry superclass to be
> abstract always to avoid people shooting themselves in the foot and
> using the wrong class by mistake.
>
> Ari
>
>
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001 fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
>
This archive was generated by hypermail 2.0.0 : Thu Apr 23 2009 - 22:35:50 EDT