[appengine-java] Re: can't update the same entity twice in a transaction or operation RAISED ONLY in JUnit tests
Hi Patrizio, It is hard to say anything without seeing your code. For me even this runs without a problem in JUnit test: PersistenceManager pm = pmf.getPersistenceManager(); pm.currentTransaction().begin(); ParentOfList p = new ParentOfList(); pm.makePersistent(p); pm.flush(); Child c = new Child(); p.getChildren().add(c); pm.makePersistent(p); pm.makePersistent(c); pm.currentTransaction().commit(); pm.close(); I am calling makePersistent() multiple times, in theory it should be failing, still it does not. Marton On Sep 25, 9:23 am, Patrizio Munzi patrizio.mu...@eris4.com wrote: Any opinion...?? Google? Patrizio Munzi wrote:Hi Marton, I think I've worked out what was the problem with my JUnit tests. I was persisting a parent entity before its children. The strange thing however is that I didn't have any problem running the same code in GAE local server. Now the question is what's the correct behavior?? I thing this could be an issue. Patrizio Munzi wrote:Hi, yep the same code runs correctly in the GAE development server. I'll send you the code ASAP. Thanks Marton Papp wrote:Hi Patrizio, I am not sure what you mean by having the error only in JUnit tests. The same code runs correctly in some other environment? Anyway, the documentation says that it is not allowed to update the same entity more than once in a single transaction. However I was not able to reproduce the problem. Could you send me some code example that fails? Thx. The docs:http://code.google.com/appengine/docs/java/datastore/transactions.html An attempt to update the same entity multiple times in a single transaction (such as with repeated makePersistent() calls) will throw a JDOFatalUserException. Instead, just modify the persistent objects within the transaction, and allow the call to commit() to apply the changes. Marton On Sep 24, 1:53 pm, Patrizio Munzipatrizio.mu...@eris4.comwrote:Hi all, I'm having this exception/error only in JUnit tests. Where's the problem? In the SDK or UNIT tests?? Thanks-- Patrizio Munzi Product Specialist Viale Bruno Buozzi, 19 - 00197 Roma (Italy) tel: +39 06 4543 3540 fax: +39 06 4543 3587 mobile: +39 393 7195 164 mail:patrizio.mu...@eris4.com web:http://www.eris4.com skype:eris4_munzi-- Patrizio Munzi Product Specialist Viale Bruno Buozzi, 19 - 00197 Roma (Italy) tel: +39 06 4543 3540 fax: +39 06 4543 3587 mobile: +39 393 7195 164 mail:patrizio.mu...@eris4.com web:http://www.eris4.com skype:eris4_munzi-- Patrizio Munzi Product Specialist Viale Bruno Buozzi, 19 - 00197 Roma (Italy) tel: +39 06 4543 3540 fax: +39 06 4543 3587 mobile: +39 393 7195 164 mail:patrizio.mu...@eris4.com web:http://www.eris4.com skype:eris4_munzi image_gif_part 1KViewDownload image_gif_part 1KViewDownload logo.gif 1KViewDownload --~--~-~--~~~---~--~~ 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-java@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: Type Owned by Two Different Types?
Hi!
Your problem is strange indeed. The interesting thing is that
persisting both types of parents works well if you do it separately.
It also works if you switch the order of persisting the objects,
starting with ParentOfOne and then ParentOfList. It also fails if you
only do a query on ParentOfList before persisting an instance of
ParentOfOne. That means persisting of ParentOfOne is failing after
ParentOfList has been recognised as a persistable class. And it
really seems to be related to mapping the children as a List, because
if I remove that mapping then everything works fine. I suggest you
raise an issue about this.
Marton
On Sep 24, 2:51 am, objectuser kevin.k.le...@gmail.com wrote:
Here's some code that reproduces my problem. Before the code, I think
it's interesting to note that I started making this example in JPA
(because I had an old test that used JPA) and I was not able to
reproduce the error. However, after converting to JDO, I get the
error. I'm not 100% sure the code is exactly the same, however, but
wanted to note it in case it's helpful to anyone.
LocalServiceTestCase is based on the examples from Google.
Does anyone see a problem with the code or is this a legit bug?
@PersistenceCapable(identityType = IdentityType.APPLICATION,
detachable = true)
public class ParentOfOne {
@PrimaryKey
@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
private Long id;
@Persistent
private SharedChild child;
...
}
@PersistenceCapable(identityType = IdentityType.APPLICATION,
detachable = true)
public class ParentOfList {
@PrimaryKey
@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
private Long id;
@Persistent
private ListSharedChild children;
...
}
@PersistenceCapable(identityType = IdentityType.APPLICATION,
detachable = true)
public class SharedChild {
@PrimaryKey
@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
private Key id;
@Persistent
private String name;
...
}
public class SharedChildTestCase extends LocalServiceTestCase {
private PersistenceManager persistenceManager;
@Before
public void openPersistenceManager() {
PersistenceManagerFactory persistenceManagerFactory =
JDOHelper
.getPersistenceManagerFactory(transactions-optional);
persistenceManager =
persistenceManagerFactory.getPersistenceManager
();
}
@After
public void closePersitenceManager() {
persistenceManager.close();
}
@Test
public void saveParents() {
ParentOfList pol = new ParentOfList();
ListSharedChild list = new ArrayListSharedChild();
SharedChild c1 = new SharedChild();
c1.setName(c1);
list.add(c1);
SharedChild c2 = new SharedChild();
c2.setName(c2);
list.add(c2);
pol.setChildren(list);
persistenceManager.makePersistent(pol);
ParentOfOne poo = new ParentOfOne();
SharedChild c3 = new SharedChild();
c1.setName(c3);
poo.setChild(c3);
persistenceManager.makePersistent(poo);
}
}
On Sep 22, 9:40 am, objectuser kevin.k.le...@gmail.com wrote:
Thanks, Marton. That's very unfortunate. The limitations still
surprise me. Is that documented somewhere? Need to go back and
reread that stuff I guess.
I'll see if I can come up with a simple test case for the collection.
On Sep 22, 3:28 am, Marton Papp mapr...@gmail.com wrote:
A class cannot have two different owned relationship to a single
class. For example if I have these two classes:
@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class Parent3 {
@PrimaryKey
@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
private Long id;
Child1 child1;
Child1 child2;
// ... get-set
}
@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class Child1 {
@PrimaryKey
@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
private Key id;
// ... get-set
}
then this code will fail with an assertion error:
public void testMultiParent2() throws Exception {
PersistenceManager pm;
Parent3 p3 = null;
Parent3 p3Loaded = null;
pm = pmf.getPersistenceManager();
pm.currentTransaction().begin();
p3 = new Parent3();
p3.setChild1(new Child1());
p3.setChild2(new Child1());
pm.makePersistent(p3
[appengine-java] Re: can't update the same entity twice in a transaction or operation RAISED ONLY in JUnit tests
Hi Patrizio, I am not sure what you mean by having the error only in JUnit tests. The same code runs correctly in some other environment? Anyway, the documentation says that it is not allowed to update the same entity more than once in a single transaction. However I was not able to reproduce the problem. Could you send me some code example that fails? Thx. The docs: http://code.google.com/appengine/docs/java/datastore/transactions.html An attempt to update the same entity multiple times in a single transaction (such as with repeated makePersistent() calls) will throw a JDOFatalUserException. Instead, just modify the persistent objects within the transaction, and allow the call to commit() to apply the changes. Marton On Sep 24, 1:53 pm, Patrizio Munzi patrizio.mu...@eris4.com wrote: Hi all, I'm having this exception/error only in JUnit tests. Where's the problem? In the SDK or UNIT tests?? Thanks --~--~-~--~~~---~--~~ 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-java@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: Seeing different (incorrect?) JDO behavior after upgrading to 1.2.5
Hi Patrizio,
I removed the _embedded=true_ attribute from the mapping of the
stat field and now it seems to be better. At least I can retrieve
the object with the correct values. I have not checked the code in
detail, but I guess if you are embedding Stat then you do not need a
primary key for it anyway.
Marton
On Sep 23, 2:39 pm, Patrizio Munzi patrizio.mu...@eris4.com wrote:
Another, I think important, information about the same problem,
the children fields doesn't show up even in the admin console.
I'm posting here my code so that everyone could check it out.--
Parent Class ---
@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class User implements IsSerializable {
@PrimaryKey
@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
@Extension(vendorName=datanucleus, key=gae.encoded-pk, value=true)
private String encodedKey;
@Persistent
private String userId;
@Persistent(embedded=true, defaultFetchGroup=true)
private Stat stat;
public User() {}
public String getEncodedKey() {
return this.encodedKey;
}
public void setEncodedKey(String encodedKey) {
this.encodedKey = encodedKey;
}
public void setUserId(String userId) {
this.userId = userId;
}
public String getUserId() {
return userId;
}
public Stat getStat() {
return stat;
}
public void setStat(Stat stat) {
this.stat = stat;
}
}
Child Class
@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class Stat implements GeneralStat {
@PrimaryKey
@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
@Extension(vendorName=datanucleus, key=gae.encoded-pk, value=true)
private String encodedKey;
@Persistent(mappedBy = stat)
private User user;
@Persistent
private String userId;
public Stat() {}
public String getEncodedKey() {
return encodedKey;
}
public void setEncodedKey(String encodedKey) {
this.encodedKey = encodedKey;
}
public String getUserId() {
return userId;
}
public void setUserId(String userId) {
this.userId = userId;
}
public User getUser() {
return user;
}
public void setUser(User user) {
this.user = user;
}
}
- Code Snippet not working --
PersistenceManager pm = PMF.get().getPersistenceManager();
String userId = test;
Key userKey = KeyFactory.createKey(User.class.getSimpleName(), userId);
String userEncodedKey = KeyFactory.keyToString(userKey);
User user = new User();
user.setUserId(userId);
user.setEncodedKey(userEncodedKey);
String statEncodedKey =
KeyFactory.keyToString(userKey.getChild(Stat.class.getSimpleName(), userId));
Stat stat = new Stat();
stat.setUserId(userId);
stat.setEncodedKey(statEncodedKey);
user.setStat(stat);
pm.makePersistent(stat);
pm.makePersistent(user);
pm.close();
pm = PMF.get().getPersistenceManager();
user = pm.getObjectById(User.class, userEncodedKey);
Stat stat = user.getStat();
-
I think I'm doing a very basic thing: persist a one-to-one bidirectional
relationship.
Am I doing something wrong??
I can't really get it work...
Please help..!!
Thanks
patrizio.munzi wrote:Hi, I'm having the same problem... When I try to fetch
an object all its children fields are null. I tried to set defaultFetchGroup
= true but nothing changed... Is there any work around for this??? I
wouldn't want to pass to an unowned relationship... Thanks On Sep 16,
11:35 pm, Jason (Google)apija...@google.comwrote:Hi bysse. You only need
to create custom indexes for composite queries, i.e. queries with two or more
sort orders or queries with an equality filter on one property and an
inequality filter on another. All single-property indexes are created by App
Engine automatically, aside from Text and Blob fields and fields you
explicitly mark as unindexed. I started seeing the same warning myself,
although the end result was exactly what I wanted. This seems to only affect
owned relationships -- if you're storing a Blob field or any other binary
data, you should be able to continue using the defaultFetchGroup parameter;
I'll have to follow up to see if there are any consequences to using this for
owned relationships given that the datastore is returning the correct result.
You can also nix the parameter and call something like getItemValues() before
you close the PersistenceManager, which will also give the intended result
without the warning. - Jason On Mon, Sep 14, 2009 at 12:01 PM,
bysseerik.byst...@gmail.comwrote:I'm having the same problem. If i
understand this correctly i must create an index for all fields in an entity.
Otherwise it will be null when i fetch the entity?If i set defaultFetchGroup
[appengine-java] Re: Best practice for modeling relationships (Java, Datastore) - list of keys or list of actual objects?!
Hi,
I think that the performance of ListPicture can actually be better
then using ListKey. Of course you should not try to retrieve the
pictures by using user.getPictures() if there are many, because it
will try to load all of them. But the difference is how it is stored
in the database. I think the values of ListKey are stored as a list
attribute of the User entity (which might have some limitations
regarding size), while in the case of ListPicture the relationship
between the User and Picture is established by defining the User
entity as the parent of the Picture entities. The latter allows you to
retrieve an arbitary subset of the pictures (or only their keys) by
using queries, while the former will load all keys when you get the
value of the collection attribute.
But, if you are having a lot of pictures per user then the
ListPicture attribute will be useless, anyway. You should rather
assign the parent of the pictures yourself (by constructing a key or
using the gae.parent-pk extension). Or if you do not need the
pictures to be in the same entity group as the parent, then you can
just create a Key (or other identifier) attribute that contains the id
of the user that the picture belongs to.
Marton
On Sep 24, 3:05 am, objectuser kevin.k.le...@gmail.com wrote:
Well, yeah, it depends on the questions you want to ask the datastore
and what you're going to do with that data. If your list is large, do
you always want to fetch the whole thing together anyway? Then an
owned relationship might be fine (but note the entity fetch limit).
Do you want to fetch things in smaller pieces? Then the model
recommended by Ieszek is probably going to serve you better.
I recommend reading about entities and entity groups and then the
articles about performance and modeling. There's a lot there that's
relevant.
On Sep 22, 8:00 am, Andreas Kristensson
andreas.kristens...@gmail.com wrote:
My thinking as well.
However, looking at GAE Java examples, tutorials, articles, etc, it's
often the other way around - i.e. keeping lists with referenced
objects... Might be that those examples outline one-to-few
relationships where it's (for some reason?! simpler?!) ok to have
lists of referenced objects instead of lists of keys to referenced
objects.
On Sep 22, 2:46 pm, leszek leszek.ptokar...@gmail.com wrote:
Much better is to keep ListKey than retrieve Pictures on demand
('paging' them) using 'batch gets' :
http://groups.google.co.uk/group/google-appengine-java/browse_frm/thr...
--~--~-~--~~~---~--~~
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-java@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: Exception when using gae.parent-pk; string cannot be converted into a Key
Hi Andreas,
The field mapped with the gae.parent-pk is expected to hold a Key
value or a key value encoded as string. Try this:
public ShoppingList(Shopper shopper) {
Key shopperKey =
KeyFactory.createKey(Shopper.class.getSimpleName(),
shopper.getEmail());
shopperEmail = KeyFactory.keyToString(shopperKey);
}
...
Of course the shopperEmail field will not contain the email anymore,
but the key of the shopper encoded as a string. You can still retrieve
the email by converting it to a Key and calling Key.getName()
(KeyFactory.stringToKey(shopperEmail).getName()).
Marton
On Sep 24, 3:13 pm, Andreas Kristensson
andreas.kristens...@gmail.com wrote:
Hi,
Trying to create ShoppingList child objects with parent set to
Shopper. Persisting Shopper works fine, but when I have created a
ShoppingList and tries to persist it I get the following exception:
javax.jdo.JDOFatalUserException: Attempt was made to set parent to
me.test...@gmail.com but this cannot be converted into a Key.
Well, email works fine as key in Shopper. Why won't it play nice with
extension gae.parent-pk? Anyone?
++ Code snippet
@PersistenceCapable(identityType = IdentityType.APPLICATION)
Shopper
{
@PrimaryKey
private String email;
...
public Shopper(String email)
{
this.email = email;
}
}
@PersistenceCapable(identityType = IdentityType.APPLICATION)
ShoppingList
{
@PrimaryKey
@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
private Key key;
@Persistent
@Extension(vendorName = datanucleus, key = gae.parent-pk, value
= true)
private String shopperEmail;
...
public ShoppingList(Shopper shopper)
{
shopperEmail = shopper.getEmail();
}
}
++ End of code snippet
--~--~-~--~~~---~--~~
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-java@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: Type Owned by Two Different Types?
A class cannot have two different owned relationship to a single
class. For example if I have these two classes:
@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class Parent3 {
@PrimaryKey
@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
private Long id;
Child1 child1;
Child1 child2;
// ... get-set
}
@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class Child1 {
@PrimaryKey
@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
private Key id;
// ... get-set
}
then this code will fail with an assertion error:
public void testMultiParent2() throws Exception {
PersistenceManager pm;
Parent3 p3 = null;
Parent3 p3Loaded = null;
pm = pmf.getPersistenceManager();
pm.currentTransaction().begin();
p3 = new Parent3();
p3.setChild1(new Child1());
p3.setChild2(new Child1());
pm.makePersistent(p3);
pm.currentTransaction().commit();
pm.close();
pm = pmf.getPersistenceManager();
pm.currentTransaction().begin();
p3Loaded = pm.getObjectById(Parent3.class, p3.getId());
Assert.assertNotSame(p3Loaded.getChild1(),
p3Loaded.getChild2());
pm.currentTransaction().commit();
pm.close();
}
It is because the datastore represents the relationship between Child1
and Parent3 instances by making the Parent3 instance the parent of the
Child1 instance. And it does the same for both Parent3.child1 and
Parent3.child2 relationships, so there is no way to tell which
property a particular instance of Child1 has been assigned to
originally.
I could not reproduce your problem with the list of children. Could
you send some code that fails for you?
Marton
On Sep 22, 3:31 am, objectuser kevin.k.le...@gmail.com wrote:
After some more testing this is what I observe:
- If A has one C property and B has two C properties, I can save both
the A and the B instances, when I get the B instance, both C
properties point to the same instance of C.
- If A has one C property and B has a property that is a List of Cs, I
get the exception in my original post.
I guess I need to work this down to a repeatable example and file a
defect report.
On Sep 21, 2:49 pm, objectuser kevin.k.le...@gmail.com wrote:
I'll let leszek talk more about the code, but I assumed that the
commented out line was just testing both scenarios. In the scenario
without comment on the line, it would be my scenario: the same owned
type but not the same owned instance.
My original question is not about one particular entity having two
parents (in an owned relationship), but having two entity groups share
the same owned Java type.
Does that make sense?
On Sep 21, 2:00 pm, Marton Papp mapr...@gmail.com wrote:
Hi,
The code in that form also works for me, but just because the
exception is caught and never reported. If you rethrow any exceptions
from the catch blocks than you should get something like the
following:
Detected attempt to establish Parent2(3) as the parent of Parent1(1)/
Child1(2) but the entity identified by Parent1(1)/Child1(2) is already
a child of Parent1(1). A parent cannot be established or changed once
an object has been persisted.
org.datanucleus.exceptions.NucleusUserException: Detected attempt to
establish Parent2(3) as the parent of Parent1(1)/Child1(2) but the
entity identified by Parent1(1)/Child1(2) is already a child of Parent1
(1). A parent cannot be established or changed once an object has
been persisted.
at
org.datanucleus.store.appengine.DatastoreRelationFieldManager.checkForParentSwitch
(DatastoreRelationFieldManager.java:214)
at org.datanucleus.store.appengine.DatastoreRelationFieldManager
$1.setObjectViaMapping(DatastoreRelationFieldManager.java:129)
at org.datanucleus.store.appengine.DatastoreRelationFieldManager
$1.apply(DatastoreRelationFieldManager.java:108)
at
org.datanucleus.store.appengine.DatastoreRelationFieldManager.storeRelations
(DatastoreRelationFieldManager.java:80)
at
org.datanucleus.store.appengine.DatastoreFieldManager.storeRelations
(DatastoreFieldManager.java:795)
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
[appengine-java] Re: JDO vs low level API
Hi Corneliu! I also had doubts about using JDO in GAE when I started to work with it. Especially because I met several bugs and it was annoying and time wasting to figure out what was going wrong. But then the bugs were fixed in the next release, so I think the guys are generally doing a good job. About the limitation with the non-existing property, you are right. It seems to me that JDO will create a property with a null value once you declare and map it. Do you have a real-life scenario where this limitation is an issue that you cannot overcome with the features provided by JDO? I think if you really need to have some entities having some properties, and others not, and still use JDO, then you could try to map different classes to the same database entity, with different properties defined in the classes. I have never tried that though, so I am not sure if it would work, and definitely would not be convenient. About mapping collections with many entities inside, I think I just wouldn't do it. If the collection is too big to be effectively loaded into memory, then you are right to be using queries instead. In this case you should not map it as a collection, but handle the parent- child relationship explicitly. But still, collection mapping can be a convenient option if you have only a small number of entities in your collection. This does not make JDO less flexible, on the contrary, it introduces an extra service. Your idea about processing just part of the results at once in a query seems to be okay. I think a similar approach is described to handle pagination of large result sets somewhere in the forums. As for me, I would not recommend you to create your own data access layer using the low level API unless you really need it or you really do not need any of the features that JDO provides. It still provides some convenient features that you would have to live without or reimplement if you decide not to use JDO (starting with mapping java classes to persistent storage, which I think is a good thing). Most of the problems you mentioned are not solved by using the low level API anyway, so if you want to create some classes that make data access easier for you applications then you can build them on top of JDO as well, without any major drawbacks. And as final reason why to use JDO, these guys who wrote the docs recommended to do so, and they must have some reason to say that. :) Marton --~--~-~--~~~---~--~~ 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-java@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: Type Owned by Two Different Types?
Hi, The code in that form also works for me, but just because the exception is caught and never reported. If you rethrow any exceptions from the catch blocks than you should get something like the following: Detected attempt to establish Parent2(3) as the parent of Parent1(1)/ Child1(2) but the entity identified by Parent1(1)/Child1(2) is already a child of Parent1(1). A parent cannot be established or changed once an object has been persisted. org.datanucleus.exceptions.NucleusUserException: Detected attempt to establish Parent2(3) as the parent of Parent1(1)/Child1(2) but the entity identified by Parent1(1)/Child1(2) is already a child of Parent1 (1). A parent cannot be established or changed once an object has been persisted. at org.datanucleus.store.appengine.DatastoreRelationFieldManager.checkForParentSwitch (DatastoreRelationFieldManager.java:214) at org.datanucleus.store.appengine.DatastoreRelationFieldManager $1.setObjectViaMapping(DatastoreRelationFieldManager.java:129) at org.datanucleus.store.appengine.DatastoreRelationFieldManager $1.apply(DatastoreRelationFieldManager.java:108) at org.datanucleus.store.appengine.DatastoreRelationFieldManager.storeRelations (DatastoreRelationFieldManager.java:80) at org.datanucleus.store.appengine.DatastoreFieldManager.storeRelations (DatastoreFieldManager.java:795) 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 hu.mapro.gae.test.forum.TestForum.testMultiParent(TestForum.java: 44) 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 org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.junit.internal.runners.MethodRoadie.runTestMethod (MethodRoadie.java:98) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java: 79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters (MethodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java: 77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod (JUnit4ClassRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods (JUnit4ClassRunner.java:51) at org.junit.internal.runners.JUnit4ClassRunner$1.run (JUnit4ClassRunner.java:44) at org.junit.internal.runners.ClassRoadie.runUnprotected (ClassRoadie.java:27) at org.junit.internal.runners.ClassRoadie.runProtected (ClassRoadie.java:37) at org.junit.internal.runners.JUnit4ClassRunner.run (JUnit4ClassRunner.java:42) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run (JUnit4TestReference.java:46) at org.eclipse.jdt.internal.junit.runner.TestExecution.run (TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests (RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests (RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run (RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main (RemoteTestRunner.java:197) The error message is self-explanatory. According to my knowledge it is impossible for a single entity to have multiple parents, just as it is impossible to change the parent of an entity (or any other part of its primary key). But you were talking about a class being in owned realationship with two different classes, not an entity. If I remove the comment from the code above that creates a new child entity before assigning it to the second parent instance then it is working as expected. Of course they will be two different employee instances with different parents (of different types).
[appengine-java] Re: Retrieve of Collection model not working
Hi,
Those two are equivalent Java constructs, and it should not be the
solution to your problem. Have you tried rewriting your code to the
original (having the return statement within the try block) and run it
again? Are you sure you have not changed anything else?
Marton
On Sep 21, 6:29 pm, Dhamu kernel...@gmail.com wrote:
my bad.. my stupid programming style I guess
I changed from
PersistenceManager pm = ...getPersistenceManager();
try {
return pm.getObjectById(MyModel.class, id);} finally {
pm.close();
}
to
PersistenceManager pm = ...getPersistenceManager();
try {
MyModel m = pm.getObjectById(MyModel.class, id);
return pm.detachCopy(m);
} finally {
pm.close();
}
and still it didn't work. and then I changed to
PersistenceManager pm = ...getPersistenceManager();
MyModel m = null, detached = null;
try {
m = pm.getObjectById(MyModel.class, id);
detached = pm.detachCopy(m);
} finally {
pm.close();}
return detached;
and hurray!!! it works now.. Thanks anyways...
Anybody know why?
On Sep 21, 2:42 pm, Dhamu kernel...@gmail.com wrote:
// MyModel
String id
ListString values
ListLong scores;
// get(id)
PersistenceManager pm = ...getPersistenceManager();
try {
return pm.getObjectById(MyModel.class, id);
} finally {
pm.close();
}
// store(obj);
PersistenceManager pm = ...getPersistenceManager();
try {
pm.makePersistent(obj);
} finally {
pm.close();
}
MyModel m = new MyModel();
m.setId(key1);
m.addValue(value1);
m.addScore(100);
store(m);
Datastore (snapshot): I can see the following values in datastore
(thats ok).
key1, [value1], [100]
if I call get(key1) and print the properties, it prints only the id
but values and scores are always null
// I am trying to update like this
MyModel m = get(key1); // values and scores property are null, only
id has the value.
m.addValue(value2);
m.addScore(200);
store(m); // this always replaces the old row in database.
i.e. now the database has only
key1, [value2], [200]
Why? Please help. I might be doing something wrong.
--~--~-~--~~~---~--~~
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-java@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: Query a collection of entities with their IDs
Hi Max,
I am surprised that this actually works. :)
I could not find the documentation describing this feature. Do you
know how is this implemented? Is it more efficient than just calling
getObjectByIdentity N (=listOfKeys.size()) times?
Thanks,
Marton
On Sep 8, 9:14 pm, Max Ross maxr+appeng...@google.com wrote:
You can do the equivalent of a low level batch get with jdoql:
Query q = pm.newQuery(select from + Flight.class.getName() + where
id == :ids);
@SuppressWarnings(unchecked)
ListFlight flights = (ListFlight) q.execute(listOfKeys);
Hope this helps,
Max
2009/9/6 Zhi Le Zou zouzh...@gmail.com
Hi,
I have a class Foo defined as below:
public class Foo{
@PrimaryKey
@Persistent(valueStrategy=
IdGeneratorStrategy.IDENTITY)
private String fooID;
...
}
Now, I have a list of IDs of the Foo entities, is it possible to retrieve
the corresponding collection of Foo entities in a single query? I found the
in the documentation, it says logic or and IN are not supported in the
java version app engine sdk, although it is supported in the python version.
Thanks in advance :-)
--
Best Regards
Robin (邹志乐）
--~--~-~--~~~---~--~~
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-java@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] HttpSession handling question
Hi!
I am using HttpSession to store some information as session
attributes. When I am testing the application locally, it works fine.
But when I upload it to production, it seems that any session
attributes that I retrieve from the session and modify it are not
persisted back to the session again, unless I specifically call
HttpSession.setAttribute() in each request. I am not sure whether it
is the expected behavior or it is bug. Here are the two test cases:
Test1:
public class Test_gae_sessionServlet extends HttpServlet {
private static final String SESSION_ATTRIBUTE_NAME =
test_session_attribute;
public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws IOException {
HttpSession session = req.getSession();
resp.setContentType(text/plain);
SessionContext sessionContext = (SessionContext)
session.getAttribute
(SESSION_ATTRIBUTE_NAME);
resp.getWriter().println(session retreived: +
sessionContext);
if (sessionContext==null) {
sessionContext = new SessionContext();
resp.getWriter().println(session created: +
sessionContext);
// calling setAttribute only when the object is first
created
resp.getWriter().println(putting context into session:
+
sessionContext);
session.setAttribute(SESSION_ATTRIBUTE_NAME,
sessionContext);
}
sessionContext.value++;
resp.getWriter().println(context at end of retquest: +
sessionContext);
}
}
Test2:
public class Test_gae_sessionServlet extends HttpServlet {
private static final String SESSION_ATTRIBUTE_NAME =
test_session_attribute;
public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws IOException {
HttpSession session = req.getSession();
resp.setContentType(text/plain);
SessionContext sessionContext = (SessionContext)
session.getAttribute
(SESSION_ATTRIBUTE_NAME);
resp.getWriter().println(session retreived: +
sessionContext);
if (sessionContext==null) {
sessionContext = new SessionContext();
resp.getWriter().println(session created: +
sessionContext);
}
// calling setAttribute in every request
resp.getWriter().println(putting context into session: +
sessionContext);
session.setAttribute(SESSION_ATTRIBUTE_NAME, sessionContext);
sessionContext.value++;
resp.getWriter().println(context at end of retquest: +
sessionContext);
}
}
The object stored in the session:
public class SessionContext implements Serializable {
private static final long serialVersionUID = -5151175222401820614L;
public int value = 0;
@Override
public String toString() {
return SessionContext [value= + value + ];
}
}
In Test1 it is always the first version of the SessionContext that is
retreived in each request, no matter that I try to change its contents
during each request. Test2 works as expected. Is it so that I need to
call HttpSession.setAttribute() for any object that is expected to
change during the request? Is it according to the servlet
specification?
Marton
--~--~-~--~~~---~--~~
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-java@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
-~--~~~~--~~--~--~---
