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
