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
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 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 :)
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
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
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
18 matches
Mail list logo