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
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.
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
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
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
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
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
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
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
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
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
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:
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 :)
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
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
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,
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,
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
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***
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
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
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
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
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
24 matches
Mail list logo
