Re: [appengine-java] Re: new in 1.2.8: relationship fields of type parent class that isn't even persisted. This is not yet supported.

[Max Ross (Google)]

I believe the exception you're getting is the result of having multiple
parents for the same type, and unfortunately that bug isn't fixed in this
release.  The bugs fixed in this release are:

- Incorrect exception for multiple fields of same type
http://code.google.com/p/datanucleus-appengine/issues/detail?id=172

- Non-persistent base classes do not work
http://code.google.com/p/datanucleus-appengine/issues/detail?id=169

- Relationships in abstract base classes don't work
http://code.google.com/p/datanucleus-appengine/issues/detail?id=171


On Sat, Dec 12, 2009 at 1:09 AM, bryce cottam bcot...@gmail.com wrote:

 hmmm I think I may have installed the patch wrong perhaps.  I
 still get the same error.
 I'm using the same code I sent you for the test case Max.  Do you see
 any tell-tale signs in here that indicate I've mis-configured
 something?  I have datanucleus-appengine-1.0.4.1-RC2.jar on my
 classpath and I removed the previous one (pretty much the same jar but
 with .final.jar as it's name.  I followed the steps outlined by
 Jonathan.

 here is the stack trace:
 java.lang.ClassCastException: oid is not instanceof
 javax.jdo.identity.ObjectIdentity
at
 com.resmark.model.RatePlan.jdoCopyKeyFieldsFromObjectId(RatePlan.java)
at
 org.datanucleus.store.mapped.mapping.PersistenceCapableMapping.setObjectAsValue(PersistenceCapableMapping.java:657)
at
 org.datanucleus.store.mapped.mapping.PersistenceCapableMapping.setObject(PersistenceCapableMapping.java:364)
at
 org.datanucleus.store.appengine.DatastoreRelationFieldManager$1.setObjectViaMapping(DatastoreRelationFieldManager.java:128)
at
 org.datanucleus.store.appengine.DatastoreRelationFieldManager$1.apply(DatastoreRelationFieldManager.java:104)
at
 org.datanucleus.store.appengine.DatastoreRelationFieldManager.storeRelations(DatastoreRelationFieldManager.java:78)
at
 org.datanucleus.store.appengine.DatastoreFieldManager.storeRelations(DatastoreFieldManager.java:812)
at
 org.datanucleus.store.appengine.DatastorePersistenceHandler.insertPostProcess(DatastorePersistenceHandler.java:288)
at
 org.datanucleus.store.appengine.DatastorePersistenceHandler.insertObjects(DatastorePersistenceHandler.java:241)
 at
 org.datanucleus.store.appengine.DatastorePersistenceHandler.insertObject(DatastorePersistenceHandler.java:225)
at
 org.datanucleus.state.JDOStateManagerImpl.internalMakePersistent(JDOStateManagerImpl.java:3185)
at
 org.datanucleus.state.JDOStateManagerImpl.makePersistent(JDOStateManagerImpl.java:3161)
at
 org.datanucleus.ObjectManagerImpl.persistObjectInternal(ObjectManagerImpl.java:1298)
 at
 org.datanucleus.ObjectManagerImpl.persistObject(ObjectManagerImpl.java:1175)
at
 org.datanucleus.jdo.JDOPersistenceManager.jdoMakePersistent(JDOPersistenceManager.java:669)
 at
 org.datanucleus.jdo.JDOPersistenceManager.makePersistent(JDOPersistenceManager.java:694)
 at com.resmark.JdoTestServlet.create(JdoTestServlet.java:183)
at com.resmark.JdoTestServlet.doTest(JdoTestServlet.java:90)
at com.resmark.JdoTestServlet.doGet(JdoTestServlet.java:33)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
 org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
at
 com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43)
at
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at
 com.google.appengine.tools.development.StaticFileFilter.doFilter(StaticFileFilter.java:121)
at
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at
 org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
at
 org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
 org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at
 org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at
 org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at
 com.google.apphosting.utils.jetty.DevAppEngineWebAppContext.handle(DevAppEngineWebAppContext.java:70)
at
 org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at
 com.google.appengine.tools.development.JettyContainerService$ApiProxyHandler.handle(JettyContainerService.java:352)
at
 org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:313)
at
 org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506)
 at
 

Re: [appengine-java] Re: new in 1.2.8: relationship fields of type parent class that isn't even persisted. This is not yet supported.

[bryce cottam]

good point, I kinda got lost in the exceptions I was getting  :)
I wound up sorting it out by making an embedded class instead of
having multiple parent classes for a given child class.  Although, it
would be nice if a child class could have different parent types.

Thanks for all your help Max.
-bryce


On Mon, Dec 14, 2009 at 11:30 AM, Max Ross (Google)
maxr+appeng...@google.com wrote:
 I believe the exception you're getting is the result of having multiple
 parents for the same type, and unfortunately that bug isn't fixed in this
 release.  The bugs fixed in this release are:

 - Incorrect exception for multiple fields of same type
 http://code.google.com/p/datanucleus-appengine/issues/detail?id=172

 - Non-persistent base classes do not work
 http://code.google.com/p/datanucleus-appengine/issues/detail?id=169

 - Relationships in abstract base classes don't work
 http://code.google.com/p/datanucleus-appengine/issues/detail?id=171


 On Sat, Dec 12, 2009 at 1:09 AM, bryce cottam bcot...@gmail.com wrote:

 hmmm I think I may have installed the patch wrong perhaps.  I
 still get the same error.
 I'm using the same code I sent you for the test case Max.  Do you see
 any tell-tale signs in here that indicate I've mis-configured
 something?  I have datanucleus-appengine-1.0.4.1-RC2.jar on my
 classpath and I removed the previous one (pretty much the same jar but
 with .final.jar as it's name.  I followed the steps outlined by
 Jonathan.

 here is the stack trace:
 java.lang.ClassCastException: oid is not instanceof
 javax.jdo.identity.ObjectIdentity
        at
 com.resmark.model.RatePlan.jdoCopyKeyFieldsFromObjectId(RatePlan.java)
        at
 org.datanucleus.store.mapped.mapping.PersistenceCapableMapping.setObjectAsValue(PersistenceCapableMapping.java:657)
        at
 org.datanucleus.store.mapped.mapping.PersistenceCapableMapping.setObject(PersistenceCapableMapping.java:364)
        at
 org.datanucleus.store.appengine.DatastoreRelationFieldManager$1.setObjectViaMapping(DatastoreRelationFieldManager.java:128)
        at
 org.datanucleus.store.appengine.DatastoreRelationFieldManager$1.apply(DatastoreRelationFieldManager.java:104)
        at
 org.datanucleus.store.appengine.DatastoreRelationFieldManager.storeRelations(DatastoreRelationFieldManager.java:78)
        at
 org.datanucleus.store.appengine.DatastoreFieldManager.storeRelations(DatastoreFieldManager.java:812)
        at
 org.datanucleus.store.appengine.DatastorePersistenceHandler.insertPostProcess(DatastorePersistenceHandler.java:288)
        at
 org.datanucleus.store.appengine.DatastorePersistenceHandler.insertObjects(DatastorePersistenceHandler.java:241)
        at
 org.datanucleus.store.appengine.DatastorePersistenceHandler.insertObject(DatastorePersistenceHandler.java:225)
        at
 org.datanucleus.state.JDOStateManagerImpl.internalMakePersistent(JDOStateManagerImpl.java:3185)
        at
 org.datanucleus.state.JDOStateManagerImpl.makePersistent(JDOStateManagerImpl.java:3161)
        at
 org.datanucleus.ObjectManagerImpl.persistObjectInternal(ObjectManagerImpl.java:1298)
        at
 org.datanucleus.ObjectManagerImpl.persistObject(ObjectManagerImpl.java:1175)
        at
 org.datanucleus.jdo.JDOPersistenceManager.jdoMakePersistent(JDOPersistenceManager.java:669)
        at
 org.datanucleus.jdo.JDOPersistenceManager.makePersistent(JDOPersistenceManager.java:694)
        at com.resmark.JdoTestServlet.create(JdoTestServlet.java:183)
        at com.resmark.JdoTestServlet.doTest(JdoTestServlet.java:90)
        at com.resmark.JdoTestServlet.doGet(JdoTestServlet.java:33)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
        at
 org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
        at
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
        at
 com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43)
        at
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
        at
 com.google.appengine.tools.development.StaticFileFilter.doFilter(StaticFileFilter.java:121)
        at
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
        at
 org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
        at
 org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
        at
 org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
        at
 org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
        at
 org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
        at
 com.google.apphosting.utils.jetty.DevAppEngineWebAppContext.handle(DevAppEngineWebAppContext.java:70)
        at
 org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
        at
 

Re: [appengine-java] Re: new in 1.2.8: relationship fields of type parent class that isn't even persisted. This is not yet supported.

[Max Ross (Google)]

Sure, sorry it was such a headache for you.  When I've got a fix ready I'll
let you know.

On Mon, Dec 14, 2009 at 10:57 AM, bryce cottam bcot...@gmail.com wrote:

 good point, I kinda got lost in the exceptions I was getting  :)
 I wound up sorting it out by making an embedded class instead of
 having multiple parent classes for a given child class.  Although, it
 would be nice if a child class could have different parent types.

 Thanks for all your help Max.
 -bryce


 On Mon, Dec 14, 2009 at 11:30 AM, Max Ross (Google)
 maxr+appeng...@google.com maxr%2bappeng...@google.com wrote:
  I believe the exception you're getting is the result of having multiple
  parents for the same type, and unfortunately that bug isn't fixed in this
  release.  The bugs fixed in this release are:
 
  - Incorrect exception for multiple fields of same type
  http://code.google.com/p/datanucleus-appengine/issues/detail?id=172
 
  - Non-persistent base classes do not work
  http://code.google.com/p/datanucleus-appengine/issues/detail?id=169
 
  - Relationships in abstract base classes don't work
  http://code.google.com/p/datanucleus-appengine/issues/detail?id=171
 
 
  On Sat, Dec 12, 2009 at 1:09 AM, bryce cottam bcot...@gmail.com wrote:
 
  hmmm I think I may have installed the patch wrong perhaps.  I
  still get the same error.
  I'm using the same code I sent you for the test case Max.  Do you see
  any tell-tale signs in here that indicate I've mis-configured
  something?  I have datanucleus-appengine-1.0.4.1-RC2.jar on my
  classpath and I removed the previous one (pretty much the same jar but
  with .final.jar as it's name.  I followed the steps outlined by
  Jonathan.
 
  here is the stack trace:
  java.lang.ClassCastException: oid is not instanceof
  javax.jdo.identity.ObjectIdentity
 at
  com.resmark.model.RatePlan.jdoCopyKeyFieldsFromObjectId(RatePlan.java)
 at
 
 org.datanucleus.store.mapped.mapping.PersistenceCapableMapping.setObjectAsValue(PersistenceCapableMapping.java:657)
 at
 
 org.datanucleus.store.mapped.mapping.PersistenceCapableMapping.setObject(PersistenceCapableMapping.java:364)
 at
 
 org.datanucleus.store.appengine.DatastoreRelationFieldManager$1.setObjectViaMapping(DatastoreRelationFieldManager.java:128)
 at
 
 org.datanucleus.store.appengine.DatastoreRelationFieldManager$1.apply(DatastoreRelationFieldManager.java:104)
 at
 
 org.datanucleus.store.appengine.DatastoreRelationFieldManager.storeRelations(DatastoreRelationFieldManager.java:78)
 at
 
 org.datanucleus.store.appengine.DatastoreFieldManager.storeRelations(DatastoreFieldManager.java:812)
 at
 
 org.datanucleus.store.appengine.DatastorePersistenceHandler.insertPostProcess(DatastorePersistenceHandler.java:288)
 at
 
 org.datanucleus.store.appengine.DatastorePersistenceHandler.insertObjects(DatastorePersistenceHandler.java:241)
 at
 
 org.datanucleus.store.appengine.DatastorePersistenceHandler.insertObject(DatastorePersistenceHandler.java:225)
 at
 
 org.datanucleus.state.JDOStateManagerImpl.internalMakePersistent(JDOStateManagerImpl.java:3185)
 at
 
 org.datanucleus.state.JDOStateManagerImpl.makePersistent(JDOStateManagerImpl.java:3161)
 at
 
 org.datanucleus.ObjectManagerImpl.persistObjectInternal(ObjectManagerImpl.java:1298)
 at
 
 org.datanucleus.ObjectManagerImpl.persistObject(ObjectManagerImpl.java:1175)
 at
 
 org.datanucleus.jdo.JDOPersistenceManager.jdoMakePersistent(JDOPersistenceManager.java:669)
 at
 
 org.datanucleus.jdo.JDOPersistenceManager.makePersistent(JDOPersistenceManager.java:694)
 at com.resmark.JdoTestServlet.create(JdoTestServlet.java:183)
 at com.resmark.JdoTestServlet.doTest(JdoTestServlet.java:90)
 at com.resmark.JdoTestServlet.doGet(JdoTestServlet.java:33)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
 at
  org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
 at
 
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
 at
 
 com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43)
 at
 
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
 at
 
 com.google.appengine.tools.development.StaticFileFilter.doFilter(StaticFileFilter.java:121)
 at
 
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
 at
  org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
 at
 
 org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
 at
  org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
 at
  org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
 at
 

[appengine-java] Re: new in 1.2.8: relationship fields of type parent class that isn't even persisted. This is not yet supported.

[Todd Vierling]

On Dec 14, 11:06 pm, Max Ross (Google) maxr+appeng...@google.com
wrote:
 Ok I've got good news for you.  I need to do more testing but I think
 different parent types for child objects should work fine as long as you use
 list-ordering for your one-to-many relationships, which you really ought to
 be doing anyway.  Position properties are already incredibly inefficient,
 and it turns out the bug you're running into only applies when there are
 position properties in play.  You can read more about it in this 
 section:http://code.google.com/appengine/docs/java/datastore/relationships.ht...
 Ordered Collections Maintain Their Order).

 So, if you change your one-to-many relationship on RatePlan to:
     @Persistent
     @Order(extensions = @Extension(vendorName=datanucleus,
 key=list-ordering, value=id))

Does this affect JPA modeling as well, and if so, how does the above
map to JPA annotations?  (I assume the value is the key field, so if
using Key, it should work too?)

--

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 google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Re: new in 1.2.8: relationship fields of type parent class that isn't even persisted. This is not yet supported.

[Max Ross (Google)]

JPA _only_ supports list-ordering (the good kind).  You can use the @OrderBy
annotation to specify the properties to order by, but even if you leave this
annotation off it will order by the primary key field.

On Mon, Dec 14, 2009 at 8:45 PM, Todd Vierling t...@duh.org wrote:


 On Dec 14, 11:06 pm, Max Ross (Google) 
 maxr+appeng...@google.commaxr%2bappeng...@google.com
 
 wrote:
  Ok I've got good news for you.  I need to do more testing but I think
  different parent types for child objects should work fine as long as you
 use
  list-ordering for your one-to-many relationships, which you really ought
 to
  be doing anyway.  Position properties are already incredibly inefficient,
  and it turns out the bug you're running into only applies when there are
  position properties in play.  You can read more about it in this section:
 http://code.google.com/appengine/docs/java/datastore/relationships.ht...
  Ordered Collections Maintain Their Order).
 
  So, if you change your one-to-many relationship on RatePlan to:
  @Persistent
  @Order(extensions = @Extension(vendorName=datanucleus,
  key=list-ordering, value=id))

 Does this affect JPA modeling as well, and if so, how does the above
 map to JPA annotations?  (I assume the value is the key field, so if
 using Key, it should work too?)

 --

 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
 google-appengine-j...@googlegroups.com.
 To unsubscribe from this group, send email to
 google-appengine-java+unsubscr...@googlegroups.comgoogle-appengine-java%2bunsubscr...@googlegroups.com
 .
 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 google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Re: new in 1.2.8: relationship fields of type parent class that isn't even persisted. This is not yet supported.

[bryce cottam]

hahaha, no that doesn't sound draconian.  I remember reading that the
ordering of lists can be a performance hit, I haven't bothered to look
too deep into it yet (since I'm only doing a proof of concept right
now).  I have some questions about it though.  For instance, what if I
were to order by some kind of displayOrder field that I maintain?
Would that also suffer a performance lag?  I mainly want to move to
the GAE for performance and scalability, so I think I'd appreciate a
runtime/compile time warning that told me about things I was doing
that would hurt my performance.

Thanks again for helping me out so much.
-bryce



On Mon, Dec 14, 2009 at 9:06 PM, Max Ross (Google)
maxr+appeng...@google.com wrote:
 Ok I've got good news for you.  I need to do more testing but I think
 different parent types for child objects should work fine as long as you use
 list-ordering for your one-to-many relationships, which you really ought to
 be doing anyway.  Position properties are already incredibly inefficient,
 and it turns out the bug you're running into only applies when there are
 position properties in play.  You can read more about it in this section:
 http://code.google.com/appengine/docs/java/datastore/relationships.html#Owned_One_to_Many_Relationships
 (How Ordered Collections Maintain Their Order).

 So, if you change your one-to-many relationship on RatePlan to:
     @Persistent
     @Order(extensions = @Extension(vendorName=datanucleus,
 key=list-ordering, value=id))
     private ListRatePlan ratePlans = new ArrayListRatePlan();

 you should be in business.

 Position properties are so bad I'm considering turning them into a meta-data
 error that you have to explicitly silence with a jvm property.  What do you
 think, too draconian?

 Max

 On Mon, Dec 14, 2009 at 11:09 AM, Max Ross (Google)
 maxr+appeng...@google.com wrote:

 Sure, sorry it was such a headache for you.  When I've got a fix ready
 I'll let you know.

 On Mon, Dec 14, 2009 at 10:57 AM, bryce cottam bcot...@gmail.com wrote:

 good point, I kinda got lost in the exceptions I was getting  :)
 I wound up sorting it out by making an embedded class instead of
 having multiple parent classes for a given child class.  Although, it
 would be nice if a child class could have different parent types.

 Thanks for all your help Max.
 -bryce


 On Mon, Dec 14, 2009 at 11:30 AM, Max Ross (Google)
 maxr+appeng...@google.com wrote:
  I believe the exception you're getting is the result of having multiple
  parents for the same type, and unfortunately that bug isn't fixed in
  this
  release.  The bugs fixed in this release are:
 
  - Incorrect exception for multiple fields of same type
  http://code.google.com/p/datanucleus-appengine/issues/detail?id=172
 
  - Non-persistent base classes do not work
  http://code.google.com/p/datanucleus-appengine/issues/detail?id=169
 
  - Relationships in abstract base classes don't work
  http://code.google.com/p/datanucleus-appengine/issues/detail?id=171
 
 
  On Sat, Dec 12, 2009 at 1:09 AM, bryce cottam bcot...@gmail.com
  wrote:
 
  hmmm I think I may have installed the patch wrong perhaps.  I
  still get the same error.
  I'm using the same code I sent you for the test case Max.  Do you see
  any tell-tale signs in here that indicate I've mis-configured
  something?  I have datanucleus-appengine-1.0.4.1-RC2.jar on my
  classpath and I removed the previous one (pretty much the same jar but
  with .final.jar as it's name.  I followed the steps outlined by
  Jonathan.
 
  here is the stack trace:
  java.lang.ClassCastException: oid is not instanceof
  javax.jdo.identity.ObjectIdentity
         at
  com.resmark.model.RatePlan.jdoCopyKeyFieldsFromObjectId(RatePlan.java)
         at
 
  org.datanucleus.store.mapped.mapping.PersistenceCapableMapping.setObjectAsValue(PersistenceCapableMapping.java:657)
         at
 
  org.datanucleus.store.mapped.mapping.PersistenceCapableMapping.setObject(PersistenceCapableMapping.java:364)
         at
 
  org.datanucleus.store.appengine.DatastoreRelationFieldManager$1.setObjectViaMapping(DatastoreRelationFieldManager.java:128)
         at
 
  org.datanucleus.store.appengine.DatastoreRelationFieldManager$1.apply(DatastoreRelationFieldManager.java:104)
         at
 
  org.datanucleus.store.appengine.DatastoreRelationFieldManager.storeRelations(DatastoreRelationFieldManager.java:78)
         at
 
  org.datanucleus.store.appengine.DatastoreFieldManager.storeRelations(DatastoreFieldManager.java:812)
         at
 
  org.datanucleus.store.appengine.DatastorePersistenceHandler.insertPostProcess(DatastorePersistenceHandler.java:288)
         at
 
  org.datanucleus.store.appengine.DatastorePersistenceHandler.insertObjects(DatastorePersistenceHandler.java:241)
         at
 
  org.datanucleus.store.appengine.DatastorePersistenceHandler.insertObject(DatastorePersistenceHandler.java:225)
         at
 
  

Re: [appengine-java] Re: new in 1.2.8: relationship fields of type parent class that isn't even persisted. This is not yet supported.

[Max Ross (Google)]

If you order by anything other than your primary key you'll take a
performance and cpu hit on writes but there won't be a penalty on your
reads.  The reason the JDO default is such a problem is that it adds an
implicit property to each child entity containing the position of that
entity in its parent's list.  If you ever remove or add an element in this
list at a location that isn't the end, everything between that element and
the end of the list needs to get shifted down.  In an RDBMS you'd just issue
an update statement to increment everything by 1 relative to its current
value, but the datastore doesn't support this type of relative update, so
ends up doing one write per entity whose index needs shifting.  So in short,
don't do it this way.  :-)

Max

On Mon, Dec 14, 2009 at 9:42 PM, bryce cottam bcot...@gmail.com wrote:

 hahaha, no that doesn't sound draconian.  I remember reading that the
 ordering of lists can be a performance hit, I haven't bothered to look
 too deep into it yet (since I'm only doing a proof of concept right
 now).  I have some questions about it though.  For instance, what if I
 were to order by some kind of displayOrder field that I maintain?
 Would that also suffer a performance lag?  I mainly want to move to
 the GAE for performance and scalability, so I think I'd appreciate a
 runtime/compile time warning that told me about things I was doing
 that would hurt my performance.

 Thanks again for helping me out so much.
 -bryce



 On Mon, Dec 14, 2009 at 9:06 PM, Max Ross (Google)
 maxr+appeng...@google.com maxr%2bappeng...@google.com wrote:
  Ok I've got good news for you.  I need to do more testing but I think
  different parent types for child objects should work fine as long as you
 use
  list-ordering for your one-to-many relationships, which you really ought
 to
  be doing anyway.  Position properties are already incredibly inefficient,
  and it turns out the bug you're running into only applies when there are
  position properties in play.  You can read more about it in this section:
 
 http://code.google.com/appengine/docs/java/datastore/relationships.html#Owned_One_to_Many_Relationships
  (How Ordered Collections Maintain Their Order).
 
  So, if you change your one-to-many relationship on RatePlan to:
  @Persistent
  @Order(extensions = @Extension(vendorName=datanucleus,
  key=list-ordering, value=id))
  private ListRatePlan ratePlans = new ArrayListRatePlan();
 
  you should be in business.
 
  Position properties are so bad I'm considering turning them into a
 meta-data
  error that you have to explicitly silence with a jvm property.  What do
 you
  think, too draconian?
 
  Max
 
  On Mon, Dec 14, 2009 at 11:09 AM, Max Ross (Google)
  maxr+appeng...@google.com maxr%2bappeng...@google.com wrote:
 
  Sure, sorry it was such a headache for you.  When I've got a fix ready
  I'll let you know.
 
  On Mon, Dec 14, 2009 at 10:57 AM, bryce cottam bcot...@gmail.com
 wrote:
 
  good point, I kinda got lost in the exceptions I was getting  :)
  I wound up sorting it out by making an embedded class instead of
  having multiple parent classes for a given child class.  Although, it
  would be nice if a child class could have different parent types.
 
  Thanks for all your help Max.
  -bryce
 
 
  On Mon, Dec 14, 2009 at 11:30 AM, Max Ross (Google)
  maxr+appeng...@google.com maxr%2bappeng...@google.com wrote:
   I believe the exception you're getting is the result of having
 multiple
   parents for the same type, and unfortunately that bug isn't fixed in
   this
   release.  The bugs fixed in this release are:
  
   - Incorrect exception for multiple fields of same type
   http://code.google.com/p/datanucleus-appengine/issues/detail?id=172
  
   - Non-persistent base classes do not work
   http://code.google.com/p/datanucleus-appengine/issues/detail?id=169
  
   - Relationships in abstract base classes don't work
   http://code.google.com/p/datanucleus-appengine/issues/detail?id=171
  
  
   On Sat, Dec 12, 2009 at 1:09 AM, bryce cottam bcot...@gmail.com
   wrote:
  
   hmmm I think I may have installed the patch wrong perhaps.  I
   still get the same error.
   I'm using the same code I sent you for the test case Max.  Do you
 see
   any tell-tale signs in here that indicate I've mis-configured
   something?  I have datanucleus-appengine-1.0.4.1-RC2.jar on my
   classpath and I removed the previous one (pretty much the same jar
 but
   with .final.jar as it's name.  I followed the steps outlined by
   Jonathan.
  
   here is the stack trace:
   java.lang.ClassCastException: oid is not instanceof
   javax.jdo.identity.ObjectIdentity
  at
  
 com.resmark.model.RatePlan.jdoCopyKeyFieldsFromObjectId(RatePlan.java)
  at
  
  
 org.datanucleus.store.mapped.mapping.PersistenceCapableMapping.setObjectAsValue(PersistenceCapableMapping.java:657)
  at
  
  
 

Re: [appengine-java] Re: new in 1.2.8: relationship fields of type parent class that isn't even persisted. This is not yet supported.

[bryce cottam]

do SortedSets suffer from the same problem?  In particular, I could
define a displayOrder property that was rather sparse (every 10th int
or something: 10, 20, 30 etc.) and if I needed to insert something
between the first and second (which shouldn't happen very often) I
could just set it's displayOrder to 15 and throw it in the set.

The only reason I bring it up, is because our app allows users to
order certain types of data (really just one type), but frankly, they
don't move them around much at all, it's pretty much defined at
creation time, but *sometimes* they alter that ordering.  I don't
anticipate this being a huge problem, heck I could sort the set after
it gets out of the datastore if I had to using a displayOrder field or
something.  I don't want to bog down my performance doing this through
some implicit index.

thanks,
-bryce


On Mon, Dec 14, 2009 at 11:04 PM, Max Ross (Google)
maxr+appeng...@google.com wrote:
 If you order by anything other than your primary key you'll take a
 performance and cpu hit on writes but there won't be a penalty on your
 reads.  The reason the JDO default is such a problem is that it adds an
 implicit property to each child entity containing the position of that
 entity in its parent's list.  If you ever remove or add an element in this
 list at a location that isn't the end, everything between that element and
 the end of the list needs to get shifted down.  In an RDBMS you'd just issue
 an update statement to increment everything by 1 relative to its current
 value, but the datastore doesn't support this type of relative update, so
 ends up doing one write per entity whose index needs shifting.  So in short,
 don't do it this way.  :-)

 Max

 On Mon, Dec 14, 2009 at 9:42 PM, bryce cottam bcot...@gmail.com wrote:

 hahaha, no that doesn't sound draconian.  I remember reading that the
 ordering of lists can be a performance hit, I haven't bothered to look
 too deep into it yet (since I'm only doing a proof of concept right
 now).  I have some questions about it though.  For instance, what if I
 were to order by some kind of displayOrder field that I maintain?
 Would that also suffer a performance lag?  I mainly want to move to
 the GAE for performance and scalability, so I think I'd appreciate a
 runtime/compile time warning that told me about things I was doing
 that would hurt my performance.

 Thanks again for helping me out so much.
 -bryce



 On Mon, Dec 14, 2009 at 9:06 PM, Max Ross (Google)
 maxr+appeng...@google.com wrote:
  Ok I've got good news for you.  I need to do more testing but I think
  different parent types for child objects should work fine as long as you
  use
  list-ordering for your one-to-many relationships, which you really ought
  to
  be doing anyway.  Position properties are already incredibly
  inefficient,
  and it turns out the bug you're running into only applies when there are
  position properties in play.  You can read more about it in this
  section:
 
  http://code.google.com/appengine/docs/java/datastore/relationships.html#Owned_One_to_Many_Relationships
  (How Ordered Collections Maintain Their Order).
 
  So, if you change your one-to-many relationship on RatePlan to:
      @Persistent
      @Order(extensions = @Extension(vendorName=datanucleus,
  key=list-ordering, value=id))
      private ListRatePlan ratePlans = new ArrayListRatePlan();
 
  you should be in business.
 
  Position properties are so bad I'm considering turning them into a
  meta-data
  error that you have to explicitly silence with a jvm property.  What do
  you
  think, too draconian?
 
  Max
 
  On Mon, Dec 14, 2009 at 11:09 AM, Max Ross (Google)
  maxr+appeng...@google.com wrote:
 
  Sure, sorry it was such a headache for you.  When I've got a fix ready
  I'll let you know.
 
  On Mon, Dec 14, 2009 at 10:57 AM, bryce cottam bcot...@gmail.com
  wrote:
 
  good point, I kinda got lost in the exceptions I was getting  :)
  I wound up sorting it out by making an embedded class instead of
  having multiple parent classes for a given child class.  Although, it
  would be nice if a child class could have different parent types.
 
  Thanks for all your help Max.
  -bryce
 
 
  On Mon, Dec 14, 2009 at 11:30 AM, Max Ross (Google)
  maxr+appeng...@google.com wrote:
   I believe the exception you're getting is the result of having
   multiple
   parents for the same type, and unfortunately that bug isn't fixed in
   this
   release.  The bugs fixed in this release are:
  
   - Incorrect exception for multiple fields of same type
   http://code.google.com/p/datanucleus-appengine/issues/detail?id=172
  
   - Non-persistent base classes do not work
   http://code.google.com/p/datanucleus-appengine/issues/detail?id=169
  
   - Relationships in abstract base classes don't work
   http://code.google.com/p/datanucleus-appengine/issues/detail?id=171
  
  
   On Sat, Dec 12, 2009 at 1:09 AM, bryce cottam bcot...@gmail.com
   wrote:
  
   hmmm I think I may have 

Re: [appengine-java] Re: new in 1.2.8: relationship fields of type parent class that isn't even persisted. This is not yet supported.

[Max Ross (Google)]

A Set will not suffer from this same problem.  The datastore has no way of
knowing what the sort function of your SortedSet might be so this will be
treated as an unordered Collection as well, but the sort will happen
in-memory as the collection is populated.  If the collection has an explicit
ordering then the JDO default is probably what you want since it does all
the shifting that you'd need to implement yourself, but there is this bug
you've run into, and I suspect there are others.  If you don't want the
overhead of a datastore index on displayOrder and you know you're not going
to have too many child objects, doing the sort in-memory may be fine.  Don't
optimize too early though.  I'd see what the performance of writes look like
with the datastore index and then go from there.

Max

On Mon, Dec 14, 2009 at 10:10 PM, bryce cottam bcot...@gmail.com wrote:

 do SortedSets suffer from the same problem?  In particular, I could
 define a displayOrder property that was rather sparse (every 10th int
 or something: 10, 20, 30 etc.) and if I needed to insert something
 between the first and second (which shouldn't happen very often) I
 could just set it's displayOrder to 15 and throw it in the set.

 The only reason I bring it up, is because our app allows users to
 order certain types of data (really just one type), but frankly, they
 don't move them around much at all, it's pretty much defined at
 creation time, but *sometimes* they alter that ordering.  I don't
 anticipate this being a huge problem, heck I could sort the set after
 it gets out of the datastore if I had to using a displayOrder field or
 something.  I don't want to bog down my performance doing this through
 some implicit index.

 thanks,
 -bryce


 On Mon, Dec 14, 2009 at 11:04 PM, Max Ross (Google)
 maxr+appeng...@google.com maxr%2bappeng...@google.com wrote:
  If you order by anything other than your primary key you'll take a
  performance and cpu hit on writes but there won't be a penalty on your
  reads.  The reason the JDO default is such a problem is that it adds an
  implicit property to each child entity containing the position of that
  entity in its parent's list.  If you ever remove or add an element in
 this
  list at a location that isn't the end, everything between that element
 and
  the end of the list needs to get shifted down.  In an RDBMS you'd just
 issue
  an update statement to increment everything by 1 relative to its current
  value, but the datastore doesn't support this type of relative update, so
  ends up doing one write per entity whose index needs shifting.  So in
 short,
  don't do it this way.  :-)
 
  Max
 
  On Mon, Dec 14, 2009 at 9:42 PM, bryce cottam bcot...@gmail.com wrote:
 
  hahaha, no that doesn't sound draconian.  I remember reading that the
  ordering of lists can be a performance hit, I haven't bothered to look
  too deep into it yet (since I'm only doing a proof of concept right
  now).  I have some questions about it though.  For instance, what if I
  were to order by some kind of displayOrder field that I maintain?
  Would that also suffer a performance lag?  I mainly want to move to
  the GAE for performance and scalability, so I think I'd appreciate a
  runtime/compile time warning that told me about things I was doing
  that would hurt my performance.
 
  Thanks again for helping me out so much.
  -bryce
 
 
 
  On Mon, Dec 14, 2009 at 9:06 PM, Max Ross (Google)
  maxr+appeng...@google.com maxr%2bappeng...@google.com wrote:
   Ok I've got good news for you.  I need to do more testing but I think
   different parent types for child objects should work fine as long as
 you
   use
   list-ordering for your one-to-many relationships, which you really
 ought
   to
   be doing anyway.  Position properties are already incredibly
   inefficient,
   and it turns out the bug you're running into only applies when there
 are
   position properties in play.  You can read more about it in this
   section:
  
  
 http://code.google.com/appengine/docs/java/datastore/relationships.html#Owned_One_to_Many_Relationships
   (How Ordered Collections Maintain Their Order).
  
   So, if you change your one-to-many relationship on RatePlan to:
   @Persistent
   @Order(extensions = @Extension(vendorName=datanucleus,
   key=list-ordering, value=id))
   private ListRatePlan ratePlans = new ArrayListRatePlan();
  
   you should be in business.
  
   Position properties are so bad I'm considering turning them into a
   meta-data
   error that you have to explicitly silence with a jvm property.  What
 do
   you
   think, too draconian?
  
   Max
  
   On Mon, Dec 14, 2009 at 11:09 AM, Max Ross (Google)
   maxr+appeng...@google.com maxr%2bappeng...@google.com wrote:
  
   Sure, sorry it was such a headache for you.  When I've got a fix
 ready
   I'll let you know.
  
   On Mon, Dec 14, 2009 at 10:57 AM, bryce cottam bcot...@gmail.com
   wrote:
  
   good point, I kinda got lost in the exceptions I was 

Re: [appengine-java] Re: new in 1.2.8: relationship fields of type parent class that isn't even persisted. This is not yet supported.

[bryce cottam]

thanks for the info.  Getting feedback like this from someone as close
to the low level implementation as yourself is priceless!

I think I'll be fine using either a SortedSet or a List with the
@Order and the datanucleus extension on it for the Activity.ratePlans
collection.  This set could just be fine to order by a name, or even
the Id.  I know there wont be too many of these children in our
clients use cases.  Even in the cases where we want to allow
user-specified ordering, the list shouldn't be that long.  We're
modeling reservations for adventure outfitters, there are only so many
people you can take down a river  :)
I'm glad to hear you say not to optimize too eagerly, I've kinda taken
the approach that I'd just make things work, and then see how I can
tweak performance as needed.

anyway, thanks again for all the great advice and info!
-bryce


On Mon, Dec 14, 2009 at 11:21 PM, Max Ross (Google)
maxr+appeng...@google.com wrote:
 A Set will not suffer from this same problem.  The datastore has no way of
 knowing what the sort function of your SortedSet might be so this will be
 treated as an unordered Collection as well, but the sort will happen
 in-memory as the collection is populated.  If the collection has an explicit
 ordering then the JDO default is probably what you want since it does all
 the shifting that you'd need to implement yourself, but there is this bug
 you've run into, and I suspect there are others.  If you don't want the
 overhead of a datastore index on displayOrder and you know you're not going
 to have too many child objects, doing the sort in-memory may be fine.  Don't
 optimize too early though.  I'd see what the performance of writes look like
 with the datastore index and then go from there.

 Max

 On Mon, Dec 14, 2009 at 10:10 PM, bryce cottam bcot...@gmail.com wrote:

 do SortedSets suffer from the same problem?  In particular, I could
 define a displayOrder property that was rather sparse (every 10th int
 or something: 10, 20, 30 etc.) and if I needed to insert something
 between the first and second (which shouldn't happen very often) I
 could just set it's displayOrder to 15 and throw it in the set.

 The only reason I bring it up, is because our app allows users to
 order certain types of data (really just one type), but frankly, they
 don't move them around much at all, it's pretty much defined at
 creation time, but *sometimes* they alter that ordering.  I don't
 anticipate this being a huge problem, heck I could sort the set after
 it gets out of the datastore if I had to using a displayOrder field or
 something.  I don't want to bog down my performance doing this through
 some implicit index.

 thanks,
 -bryce


 On Mon, Dec 14, 2009 at 11:04 PM, Max Ross (Google)
 maxr+appeng...@google.com wrote:
  If you order by anything other than your primary key you'll take a
  performance and cpu hit on writes but there won't be a penalty on your
  reads.  The reason the JDO default is such a problem is that it adds an
  implicit property to each child entity containing the position of that
  entity in its parent's list.  If you ever remove or add an element in
  this
  list at a location that isn't the end, everything between that element
  and
  the end of the list needs to get shifted down.  In an RDBMS you'd just
  issue
  an update statement to increment everything by 1 relative to its current
  value, but the datastore doesn't support this type of relative update,
  so
  ends up doing one write per entity whose index needs shifting.  So in
  short,
  don't do it this way.  :-)
 
  Max
 
  On Mon, Dec 14, 2009 at 9:42 PM, bryce cottam bcot...@gmail.com wrote:
 
  hahaha, no that doesn't sound draconian.  I remember reading that the
  ordering of lists can be a performance hit, I haven't bothered to look
  too deep into it yet (since I'm only doing a proof of concept right
  now).  I have some questions about it though.  For instance, what if I
  were to order by some kind of displayOrder field that I maintain?
  Would that also suffer a performance lag?  I mainly want to move to
  the GAE for performance and scalability, so I think I'd appreciate a
  runtime/compile time warning that told me about things I was doing
  that would hurt my performance.
 
  Thanks again for helping me out so much.
  -bryce
 
 
 
  On Mon, Dec 14, 2009 at 9:06 PM, Max Ross (Google)
  maxr+appeng...@google.com wrote:
   Ok I've got good news for you.  I need to do more testing but I think
   different parent types for child objects should work fine as long as
   you
   use
   list-ordering for your one-to-many relationships, which you really
   ought
   to
   be doing anyway.  Position properties are already incredibly
   inefficient,
   and it turns out the bug you're running into only applies when there
   are
   position properties in play.  You can read more about it in this
   section:
  
  
   

Re: [appengine-java] Re: new in 1.2.8: relationship fields of type parent class that isn't even persisted. This is not yet supported.

[bryce cottam]

hmmm I think I may have installed the patch wrong perhaps.  I
still get the same error.
I'm using the same code I sent you for the test case Max.  Do you see
any tell-tale signs in here that indicate I've mis-configured
something?  I have datanucleus-appengine-1.0.4.1-RC2.jar on my
classpath and I removed the previous one (pretty much the same jar but
with .final.jar as it's name.  I followed the steps outlined by
Jonathan.

here is the stack trace:
java.lang.ClassCastException: oid is not instanceof
javax.jdo.identity.ObjectIdentity
at 
com.resmark.model.RatePlan.jdoCopyKeyFieldsFromObjectId(RatePlan.java)
at 
org.datanucleus.store.mapped.mapping.PersistenceCapableMapping.setObjectAsValue(PersistenceCapableMapping.java:657)
at 
org.datanucleus.store.mapped.mapping.PersistenceCapableMapping.setObject(PersistenceCapableMapping.java:364)
at 
org.datanucleus.store.appengine.DatastoreRelationFieldManager$1.setObjectViaMapping(DatastoreRelationFieldManager.java:128)
at 
org.datanucleus.store.appengine.DatastoreRelationFieldManager$1.apply(DatastoreRelationFieldManager.java:104)
at 
org.datanucleus.store.appengine.DatastoreRelationFieldManager.storeRelations(DatastoreRelationFieldManager.java:78)
at 
org.datanucleus.store.appengine.DatastoreFieldManager.storeRelations(DatastoreFieldManager.java:812)
at 
org.datanucleus.store.appengine.DatastorePersistenceHandler.insertPostProcess(DatastorePersistenceHandler.java:288)
at 
org.datanucleus.store.appengine.DatastorePersistenceHandler.insertObjects(DatastorePersistenceHandler.java:241)
at 
org.datanucleus.store.appengine.DatastorePersistenceHandler.insertObject(DatastorePersistenceHandler.java:225)
at 
org.datanucleus.state.JDOStateManagerImpl.internalMakePersistent(JDOStateManagerImpl.java:3185)
at 
org.datanucleus.state.JDOStateManagerImpl.makePersistent(JDOStateManagerImpl.java:3161)
at 
org.datanucleus.ObjectManagerImpl.persistObjectInternal(ObjectManagerImpl.java:1298)
at 
org.datanucleus.ObjectManagerImpl.persistObject(ObjectManagerImpl.java:1175)
at 
org.datanucleus.jdo.JDOPersistenceManager.jdoMakePersistent(JDOPersistenceManager.java:669)
at 
org.datanucleus.jdo.JDOPersistenceManager.makePersistent(JDOPersistenceManager.java:694)
at com.resmark.JdoTestServlet.create(JdoTestServlet.java:183)
at com.resmark.JdoTestServlet.doTest(JdoTestServlet.java:90)
at com.resmark.JdoTestServlet.doGet(JdoTestServlet.java:33)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at 
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
at 
com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43)
at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at 
com.google.appengine.tools.development.StaticFileFilter.doFilter(StaticFileFilter.java:121)
at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at 
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
at 
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at 
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at 
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at 
com.google.apphosting.utils.jetty.DevAppEngineWebAppContext.handle(DevAppEngineWebAppContext.java:70)
at 
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at 
com.google.appengine.tools.development.JettyContainerService$ApiProxyHandler.handle(JettyContainerService.java:352)
at 
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:313)
at 
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506)
at 
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:830)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
at 
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396)
at 
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)

I've got to be missing something.  :(

thanks,
-bryce


On Fri, Dec 11, 2009 at 8:54 AM, bryce cottam bcot...@gmail.com wrote:
 Thanks a million Max, I've been on the road for a few days but I'm looking
 

[appengine-java] Re: new in 1.2.8: relationship fields of type parent class that isn't even persisted. This is not yet supported.

[Jonathan 'J5' Cook]

Thanks for the fix, Max and perfect timing for me :)  I just upgraded
to 1.2.8 and started having this issue last night.

For those who don't/didn't already know (like myself), here is a link
to instructions Max wrote on how to install a new plugin version into
the SDK:

http://code.google.com/p/datanucleus-appengine/wiki/HowToUpdateTheSDKWithANewPluginVersion

Regards,
J5

On Dec 10, 11:59 am, Max Ross (Google) maxr+appeng...@google.com
wrote:
 I've posted a bug fix release candidate containing this fix 
 here:http://datanucleus-appengine.googlecode.com/files/appengine-orm-1.0.4...

 On Tue, Dec 8, 2009 at 5:26 PM, bryce cottam bcot...@gmail.com wrote:
  That's great news Max! Thanks so much for looking into this and getting a
  solution in the works so fast.

  Thanks,
  -bryce

  On Dec 8, 2009 5:20 PM, Max Ross (Google) 
  maxr+appeng...@google.commaxr%2bappeng...@google.com
  wrote:

  I've filed bug
 http://code.google.com/p/datanucleus-appengine/issues/detail?id=169to
  track the problem with non-persistent base classes.  I have a fix in the
  works.  I'll be posting a release candidate with this fix and hopefully a
  few others in the next day or two.

  Thanks,
  Max

  On Tue, Dec 8, 2009 at 11:29 AM, bryce cottam bcot...@gmail.com wrote:

It's all good, we're just trying to get to the bottom of the issue.
  I'm sure the use of the word...

  --

You received this message because you are subscribed to the Google
  Groups Google App Engine fo...

  -- You received this message because you are subscribed to the Google
  Groups Google App Engine f...

   --
  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
  google-appengine-j...@googlegroups.com.
  To unsubscribe from this group, send email to
  google-appengine-java+unsubscr...@googlegroups.comgoogle-appengine-java%2bunsubscr...@googlegroups.com
  .
  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 google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Re: new in 1.2.8: relationship fields of type parent class that isn't even persisted. This is not yet supported.

[bryce cottam]

Thanks a million Max, I've been on the road for a few days but I'm looking
forward to trying this out when I get back. Thanks for the link Jonathan.

-bryce

On Dec 11, 2009 6:50 AM, Jonathan apos;J5apos; Cook 
jonathan.j5.c...@gmail.com wrote:

Thanks for the fix, Max and perfect timing for me :)  I just upgraded
to 1.2.8 and started having this issue last night.

For those who don't/didn't already know (like myself), here is a link
to instructions Max wrote on how to install a new plugin version into
the SDK:

http://code.google.com/p/datanucleus-appengine/wiki/HowToUpdateTheSDKWithANewPluginVersion

Regards,
J5

On Dec 10, 11:59 am, Max Ross (Google)
maxr+appeng...@google.commaxr%2bappeng...@google.com

wrote:
 I've posted a bug fix release candidate containing this fix here:
http://datanucleus-appengine.googlecode.com/files/appengine-orm-1.0.4...

  On Tue, Dec 8, 2009 at 5:26 PM, bryce cottam bcot...@gmail.com wrote:
  That's great news Ma...
  On Dec 8, 2009 5:20 PM, Max Ross (Google) 
  maxr+appeng...@google.commaxr%2bappeng...@google.com
maxr%2bappeng...@google.com maxr%252bappeng...@google.com

  wrote:I've filed bug  
http://code.google.com/p/datanucleus-appengine/issues/detail?id=1...

  On Tue, Dec 8, 2009 at 11:29 AM, bryce cottam bcot...@gmail.com wrote:
 It's all goo...
  google-appengine-java+unsubscr...@googlegroups.comgoogle-appengine-java%2bunsubscr...@googlegroups.com
google-appengine-java%2bunsubscr...@googlegroups.comgoogle-appengine-java%252bunsubscr...@googlegroups.com


  .   For more options, visit this group at  
http://groups.google.com/group/google-appengine-j...

--

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 google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

[appengine-java] Re: new in 1.2.8: relationship fields of type parent class that isn't even persisted. This is not yet supported.

[yongli2001cn]

hi,

It's lucky to see this thread.

I have been spent two days struggling with exactly the same problem as
Bryce.

Basically, two problems:
1) why the enhancer complains that BaseObject need to be enhanced even
though it does not declare any fields ?

2)  if I declare BaseObject as PersistenceCapable, the appengine
runtime complains that subclass are multiple relationships of the
same type are detected. However such relationships are inevitable
because all model classes extend the base.

And now,
the 2nd problem has been overcomed by the link provided by Max.
Thanks, Max.
However I still desire 1st problem could be addressed.

I just want a class structure like:

// do not have persistent annotation here
abstract class BaseObject {
   // ... some common methods | abstract methods
}

@PersistenceCapable
class A extends BaseObject
class B extends BaseObject
...

On Dec 8, 2:38 pm, bryce cottam bcot...@gmail.com wrote:
 Thanks for the link Max.

 Having BaseBean be PersistenceCapable isn't really a requirement.
 It'd be nice, 'cause pretty much every bean in my class structure is
 going to have an id field, a getter/setter and the exact same JDO
 annotation metadata on that field.  It'd be nice to just have that
 defined once in a base class.  However, it's no big thing to just
 implement an id field on every class, so I can certainly do without
 BaseBean being persistable.  However, I'm noticing above mentioned
 errors when I make BaseBean a plain-ol class with no persistence
 metadata (i.e. it just implements equals and hashCode) and the
 appengine datanucleus plugin seems to be telling me that BaseBean
 needs to be enhanced.  So, either way I go, I'm running into issues.
 I'd like to try to get to the bottom of why my non-persistable base
 class is being required to have been enhanced.  Perhaps something is
 wrong with my configuration/meta data?  perhaps a bug?

 any feedback/suggestions would be great.
 thanks!
 -bryce

 On Mon, Dec 7, 2009 at 12:04 PM, Max Ross (Google)

 maxr+appeng...@google.com wrote:
  I need to investigate the requirement that BaseBean be PersistenceCapable,
  but the relationship exception you're getting is most likely the result of a
  separate bug.  Here's a thread with the workaround:
 https://groups.google.com/group/google-appengine-java/browse_thread/t...

  Max

  On Mon, Dec 7, 2009 at 1:41 AM, bryce cottam bcot...@gmail.com wrote:

  right, we're certainly on the same page on what should/shouldn't be
  persisted.  I have that override on every single class that subclasses
  BaseBean.  I would never expect JDO/datanucleus or any other framework
  for that matter to magically persist a field in a non-peristable
  super class.  That's why I override it in every subclass.  Again, I
  had it in there as a place holder until GAE supported persisting super
  class fields in subclasses.  in the release notes of 1.2.8 of GAE, it
  indicates such functionality is available, so I removed my overrides,
  made BaseBean persistable and started testing.  Once I saw the error
  in my original message, I reverted everything back to a state where
  BaseBean is not persistable, and in fact, it is abstract and I removed
  the implementation of the id field and property getter/setters and
  migrated that all down to each subclassing bean.  So, given my code
  above, no one should be requiring BaseBean to be persistable or even
  enhanced.  Good tip on the point that a plugin may be causing this,
  here is the stack trace I posted earlier:

  Persistent class Class com.resmark.client.model.BaseBean does not
  seem to have been enhanced.  You may want to rerun the enhancer and
  check for errors in the output. has no table in the database, but the
  operation requires it. Please check the specification of the MetaData
  for this class.
        at
  org.datanucleus.jdo.NucleusJDOHelper.getJDOExceptionForNucleusException(NucleusJDOHelper.java:375)
        at
  org.datanucleus.jdo.JDOPersistenceManager.jdoMakePersistent(JDOPersistenceManager.java:674)
        at
  org.datanucleus.jdo.JDOPersistenceManager.makePersistent(JDOPersistenceManager.java:694)
        at
  com.resmark.server.model.service.BaseDataService.create(BaseDataService.java:227)
        at
  com.resmark.server.SetupServiceImpl.updateOrCreate(SetupServiceImpl.java:123)
        at
  com.resmark.server.SetupServiceImpl.updateOrCreateActivity(SetupServiceImpl.java:60)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
  sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at
  sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at
  com.google.appengine.tools.development.agent.runtime.Runtime.invoke(Runtime.java:100)
        at
  com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:527)
        at
  

[appengine-java] Re: new in 1.2.8: relationship fields of type parent class that isn't even persisted. This is not yet supported.

[datanucleus]

 1) why the enhancer complains that BaseObject need to be enhanced even
 though it does not declare any fields ?

There is no problem presented here with the enhancer complaining.
All is at runtime actually, thrown from a call by GAE/J's DN plugin,
as shown by the stack trace above. As I've already stated, DataNucleus
does NOT require any base class to be persistent when the classes are
declared as I've already shown. If you have some other situation then
demonstrate it

--

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 google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Re: new in 1.2.8: relationship fields of type parent class that isn't even persisted. This is not yet supported.

[bryce cottam]

It's all good, we're just trying to get to the bottom of the issue. I'm sure
the use of the word enhancer was just contextual. You have indeed
demonstrated that datanucleus isn't complaining. We're all friends here :)
thanks for helping us narrow the the root cause of the problem down.

Thanks,
-bryce

On Dec 8, 2009 11:18 AM, datanucleus andy_jeffer...@yahoo.com wrote:

 1) why the enhancer complains that BaseObject need to be enhanced even 
though it does not declar...
There is no problem presented here with the enhancer complaining.
All is at runtime actually, thrown from a call by GAE/J's DN plugin,
as shown by the stack trace above. As I've already stated, DataNucleus
does NOT require any base class to be persistent when the classes are
declared as I've already shown. If you have some other situation then
demonstrate it

-- You received this message because you are subscribed to the Google Groups
Google App Engine fo...

--

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 google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Re: new in 1.2.8: relationship fields of type parent class that isn't even persisted. This is not yet supported.

[Max Ross (Google)]

I've filed bug
http://code.google.com/p/datanucleus-appengine/issues/detail?id=169 to track
the problem with non-persistent base classes.  I have a fix in the works.
I'll be posting a release candidate with this fix and hopefully a few others
in the next day or two.

Thanks,
Max

On Tue, Dec 8, 2009 at 11:29 AM, bryce cottam bcot...@gmail.com wrote:

 It's all good, we're just trying to get to the bottom of the issue. I'm
 sure the use of the word enhancer was just contextual. You have indeed
 demonstrated that datanucleus isn't complaining. We're all friends here :)
 thanks for helping us narrow the the root cause of the problem down.

 Thanks,
 -bryce

 On Dec 8, 2009 11:18 AM, datanucleus andy_jeffer...@yahoo.com wrote:

  1) why the enhancer complains that BaseObject need to be enhanced even 
 though it does not declar...
 There is no problem presented here with the enhancer complaining.
 All is at runtime actually, thrown from a call by GAE/J's DN plugin,
 as shown by the stack trace above. As I've already stated, DataNucleus
 does NOT require any base class to be persistent when the classes are
 declared as I've already shown. If you have some other situation then
 demonstrate it

 -- You received this message because you are subscribed to the Google
 Groups Google App Engine fo...

  --
 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
 google-appengine-j...@googlegroups.com.
 To unsubscribe from this group, send email to
 google-appengine-java+unsubscr...@googlegroups.comgoogle-appengine-java%2bunsubscr...@googlegroups.com
 .
 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 google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Re: new in 1.2.8: relationship fields of type parent class that isn't even persisted. This is not yet supported.

[bryce cottam]

That's great news Max! Thanks so much for looking into this and getting a
solution in the works so fast.

Thanks,
-bryce

On Dec 8, 2009 5:20 PM, Max Ross (Google)
maxr+appeng...@google.commaxr%2bappeng...@google.com
wrote:

I've filed bug
http://code.google.com/p/datanucleus-appengine/issues/detail?id=169 to track
the problem with non-persistent base classes.  I have a fix in the works.
I'll be posting a release candidate with this fix and hopefully a few others
in the next day or two.

Thanks,
Max

On Tue, Dec 8, 2009 at 11:29 AM, bryce cottam bcot...@gmail.com wrote:

   It's all good, we're just trying to get to the bottom of the issue. I'm
 sure the use of the word...

 --

   You received this message because you are subscribed to the Google
 Groups Google App Engine fo...

-- You received this message because you are subscribed to the Google Groups
Google App Engine f...

--

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 google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

[appengine-java] Re: new in 1.2.8: relationship fields of type parent class that isn't even persisted. This is not yet supported.

[datanucleus]

 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 google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Re: new in 1.2.8: relationship fields of type parent class that isn't even persisted. This is not yet supported.

[bryce cottam]

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 andy_jeffer...@yahoo.com 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 google-appengine-j...@googlegroups.com.
 To unsubscribe from this group, send email to 
 google-appengine-java+unsubscr...@googlegroups.com.
 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 google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Re: new in 1.2.8: relationship fields of type parent class that isn't even persisted. This is not yet supported.

[bryce cottam]

oh, forgot to mention:
if according to the JDO specs a non-persistent super class can have
a field that is overridden by it's persistent sub-classes, then it
seems like a bug that I was getting runtime errors saying that
BaseBean isn't persistable when trying to persist a subclass of
BaseBean that was persistable:

Persistent class Class com.resmark.client.model.BaseBean does not
seem to have been enhanced.  You may want to rerun the enhancer and
check for errors in the output. has no table in the database, but the
operation requires it. Please check the specification of the MetaData
for this class.
at 
org.datanucleus.jdo.NucleusJDOHelper.getJDOExceptionForNucleusException(NucleusJDOHelper.java:375)
at 
org.datanucleus.jdo.JDOPersistenceManager.jdoMakePersistent(JDOPersistenceManager.java:674)
at 
org.datanucleus.jdo.JDOPersistenceManager.makePersistent(JDOPersistenceManager.java:694)
at 
com.resmark.server.model.service.BaseDataService.create(BaseDataService.java:227)
at 
com.resmark.server.SetupServiceImpl.updateOrCreate(SetupServiceImpl.java:123)
at 
com.resmark.server.SetupServiceImpl.updateOrCreateActivity(SetupServiceImpl.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
com.google.appengine.tools.development.agent.runtime.Runtime.invoke(Runtime.java:100)
at 
com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:527)
at 
com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:166)
at 
com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost(RemoteServiceServlet.java:86)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at 
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
at 
com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43)
at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at 
com.google.appengine.tools.development.StaticFileFilter.doFilter(StaticFileFilter.java:121)
at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at 
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
at 
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at 
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at 
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at 
com.google.apphosting.utils.jetty.DevAppEngineWebAppContext.handle(DevAppEngineWebAppContext.java:70)
at 
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at 
com.google.appengine.tools.development.JettyContainerService$ApiProxyHandler.handle(JettyContainerService.java:352)
at 
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:313)
at 
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506)
at 
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:844)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:644)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
at 
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396)
at 
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)


that stack trace comes from this model:
public abstract class BaseBean implements IsSerializable,
Serializable, Identifiable
{
private static final long serialVersionUID = 1L;

private Integer hash;

@Override
@SuppressWarnings(unchecked)
public boolean equals(Object obj)
{
if (this == obj)
{
return true;
}
if (obj == null)
{
return false;
}

boolean equal = false;
if (getClass().equals(obj.getClass()))
{
BaseBean that = (BaseBean) obj;
Object thisId = this.getId();
Object thatId = that.getId();
  

[appengine-java] Re: new in 1.2.8: relationship fields of type parent class that isn't even persisted. This is not yet supported.

[datanucleus]

Let's be clear here, if you have
public class Base
{
private long id;

public long getId()
{
return id;
}

public void setId(long id)
{
this.id = id;
}
}
@PersistenceCapable
public class Sub extends Base
{
@PrimaryKey
@Persistent
public long getId()
{
 return super.getId();
}
public void setId(long id)
{
 super.setId(id);
}
}

and persist a Sub, then ***DataNucleus*** will *not* insist that the
superclass is persistable. This is based on all DN datastore plugins
except GAE/J. If GAE/J does cause this then it is a bug in that plugin
and raise a bug on them, with stack trace and exception etc etc.

Also to be clear, the JDO and JPA specs do *not* allow magical
persistence of a field of a non-persistable superclass, unless you do
an override in a subclass like what you did there (to make it a
persistable property). You will *always* need that override.

--

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 google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Re: new in 1.2.8: relationship fields of type parent class that isn't even persisted. This is not yet supported.

[bryce cottam]

right, we're certainly on the same page on what should/shouldn't be
persisted.  I have that override on every single class that subclasses
BaseBean.  I would never expect JDO/datanucleus or any other framework
for that matter to magically persist a field in a non-peristable
super class.  That's why I override it in every subclass.  Again, I
had it in there as a place holder until GAE supported persisting super
class fields in subclasses.  in the release notes of 1.2.8 of GAE, it
indicates such functionality is available, so I removed my overrides,
made BaseBean persistable and started testing.  Once I saw the error
in my original message, I reverted everything back to a state where
BaseBean is not persistable, and in fact, it is abstract and I removed
the implementation of the id field and property getter/setters and
migrated that all down to each subclassing bean.  So, given my code
above, no one should be requiring BaseBean to be persistable or even
enhanced.  Good tip on the point that a plugin may be causing this,
here is the stack trace I posted earlier:

Persistent class Class com.resmark.client.model.BaseBean does not
seem to have been enhanced.  You may want to rerun the enhancer and
check for errors in the output. has no table in the database, but the
operation requires it. Please check the specification of the MetaData
for this class.
   at 
org.datanucleus.jdo.NucleusJDOHelper.getJDOExceptionForNucleusException(NucleusJDOHelper.java:375)
   at 
org.datanucleus.jdo.JDOPersistenceManager.jdoMakePersistent(JDOPersistenceManager.java:674)
   at 
org.datanucleus.jdo.JDOPersistenceManager.makePersistent(JDOPersistenceManager.java:694)
   at 
com.resmark.server.model.service.BaseDataService.create(BaseDataService.java:227)
   at 
com.resmark.server.SetupServiceImpl.updateOrCreate(SetupServiceImpl.java:123)
   at 
com.resmark.server.SetupServiceImpl.updateOrCreateActivity(SetupServiceImpl.java:60)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
com.google.appengine.tools.development.agent.runtime.Runtime.invoke(Runtime.java:100)
   at 
com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:527)
   at 
com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:166)
   at 
com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost(RemoteServiceServlet.java:86)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
   at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
   at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
   at 
com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43)
   at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
   at 
com.google.appengine.tools.development.StaticFileFilter.doFilter(StaticFileFilter.java:121)
   at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
   at 
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
   at 
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
   at 
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
   at 
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
   at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
   at 
com.google.apphosting.utils.jetty.DevAppEngineWebAppContext.handle(DevAppEngineWebAppContext.java:70)
   at 
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
   at 
com.google.appengine.tools.development.JettyContainerService$ApiProxyHandler.handle(JettyContainerService.java:352)
   at 
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
   at org.mortbay.jetty.Server.handle(Server.java:313)
   at 
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506)
   at 
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:844)
   at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:644)
   at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
   at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
   at 
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396)
   at 
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)

and I guess I glanced over it before, but here's the nested stack trace:
Persistent class Class com.resmark.client.model.BaseBean does not

Re: [appengine-java] Re: new in 1.2.8: relationship fields of type parent class that isn't even persisted. This is not yet supported.

[bryce cottam]

Thanks for the link Max.

Having BaseBean be PersistenceCapable isn't really a requirement.
It'd be nice, 'cause pretty much every bean in my class structure is
going to have an id field, a getter/setter and the exact same JDO
annotation metadata on that field.  It'd be nice to just have that
defined once in a base class.  However, it's no big thing to just
implement an id field on every class, so I can certainly do without
BaseBean being persistable.  However, I'm noticing above mentioned
errors when I make BaseBean a plain-ol class with no persistence
metadata (i.e. it just implements equals and hashCode) and the
appengine datanucleus plugin seems to be telling me that BaseBean
needs to be enhanced.  So, either way I go, I'm running into issues.
I'd like to try to get to the bottom of why my non-persistable base
class is being required to have been enhanced.  Perhaps something is
wrong with my configuration/meta data?  perhaps a bug?

any feedback/suggestions would be great.
thanks!
-bryce



On Mon, Dec 7, 2009 at 12:04 PM, Max Ross (Google)
maxr+appeng...@google.com wrote:
 I need to investigate the requirement that BaseBean be PersistenceCapable,
 but the relationship exception you're getting is most likely the result of a
 separate bug.  Here's a thread with the workaround:
 https://groups.google.com/group/google-appengine-java/browse_thread/thread/241f366dde05f9f3#

 Max

 On Mon, Dec 7, 2009 at 1:41 AM, bryce cottam bcot...@gmail.com wrote:

 right, we're certainly on the same page on what should/shouldn't be
 persisted.  I have that override on every single class that subclasses
 BaseBean.  I would never expect JDO/datanucleus or any other framework
 for that matter to magically persist a field in a non-peristable
 super class.  That's why I override it in every subclass.  Again, I
 had it in there as a place holder until GAE supported persisting super
 class fields in subclasses.  in the release notes of 1.2.8 of GAE, it
 indicates such functionality is available, so I removed my overrides,
 made BaseBean persistable and started testing.  Once I saw the error
 in my original message, I reverted everything back to a state where
 BaseBean is not persistable, and in fact, it is abstract and I removed
 the implementation of the id field and property getter/setters and
 migrated that all down to each subclassing bean.  So, given my code
 above, no one should be requiring BaseBean to be persistable or even
 enhanced.  Good tip on the point that a plugin may be causing this,
 here is the stack trace I posted earlier:

 Persistent class Class com.resmark.client.model.BaseBean does not
 seem to have been enhanced.  You may want to rerun the enhancer and
 check for errors in the output. has no table in the database, but the
 operation requires it. Please check the specification of the MetaData
 for this class.
       at
 org.datanucleus.jdo.NucleusJDOHelper.getJDOExceptionForNucleusException(NucleusJDOHelper.java:375)
       at
 org.datanucleus.jdo.JDOPersistenceManager.jdoMakePersistent(JDOPersistenceManager.java:674)
       at
 org.datanucleus.jdo.JDOPersistenceManager.makePersistent(JDOPersistenceManager.java:694)
       at
 com.resmark.server.model.service.BaseDataService.create(BaseDataService.java:227)
       at
 com.resmark.server.SetupServiceImpl.updateOrCreate(SetupServiceImpl.java:123)
       at
 com.resmark.server.SetupServiceImpl.updateOrCreateActivity(SetupServiceImpl.java:60)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
       at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:597)
       at
 com.google.appengine.tools.development.agent.runtime.Runtime.invoke(Runtime.java:100)
       at
 com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:527)
       at
 com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:166)
       at
 com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost(RemoteServiceServlet.java:86)
       at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
       at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
       at
 org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
       at
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
       at
 com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43)
       at
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
       at
 com.google.appengine.tools.development.StaticFileFilter.doFilter(StaticFileFilter.java:121)
       at
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
       at
 org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
       at