well, I should clarify:
BaseBean used to just hold the field id:
private Key id;
public Key getId()
{
return id;
}
public void setId(Key id)
{
this.id = id;
}
and subclasses would override this method and put the appropriate JDO
annotations in. I was doing this because inheritance of this type
wasn't supported when I stared writing my app:
public class SomeSubClass extends BaseBean
{
@Override
@PrimaryKey
@Persistent(valueStrategy=IdGeneratorStrategy.IDENTITY)
public Key getId()
{
return super.getId();
}
public void setId(Key id)
{
super.setKey(id);
}
...
}
now, again, I was only doing this as a fill-gap because I knew that
subclassing and persisting a super class's fields would be supported
in a future release of the sdk.
so, when I first updated to 1.2.8, I didn't change anything about any
class. i.e. BaseBean was still a simple POJO with no annotations, and
simply had a field/property in common
with it's persistable sub-classes. I'm not sure why JDO would feel
the need to have BaseBean persisted in this case, given that the only
fields on that class are clearly overriden in it's subclasses.
However, that aside, it still seems like a problem if you have 2
relationships, one of type one-to-one and another of type one-to-many
that are completely different (both at compile time and at runtime)
that *happen* to share a common ancestor (which is never persisted)
and your persistence wrapper thinks they are realationships of the
same data type.
not sure if I'm making that clear, sorry I left out that detail in the
first place, but my main point is independent of it: the relationships
are different, with different comple and runtime types. They
shouldn't ever be considered the same type. I mean, everythings an
Object but you don't get this error when that happens.
On Mon, Dec 7, 2009 at 1:28 AM, datanucleus <[email protected]> wrote:
>> It also is the central place for entities "id" field:
>
> DataNucleus, the project (as opposed to the Google plugin), only
> "insists" that something is enhanced if you are using its fields/
> properties as persistent. If this class has an "id" field and you
> expect that field to be persisted then ***JDO*** (or JPA for that
> matter too) requires that this class is persistable. If instead you
> have a field "id" in that class yet you define a (persistent) property
> (getId()/setId()) in the persistable subclasses as then that
> superclass doesn't have to be persistable ... i.e as per the JDO/JPA
> specs
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Google App Engine for Java" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/google-appengine-java?hl=en.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Google App Engine for Java" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en.
