I'm hoping someone's seen this. I've found no clues on Google.
I'm using Google AppEngine with JDO to persist my objects.
I have two objects, Parent and Child. Each Parent has n Child objects.
I initially stored the Child objects in an ArrayList data member in the Parent class.
I got the exception "java.lang.UnsupportedOperationException: FK Arrays not supported" when persisting the Parent object.
I put this down to my storing more than one Child key references, so changed it around so that the Child objects store key references to the Parent object instead. In this way, there is only one key reference per Child object instead of n key references per Parent object.
Yet the exception still gets thrown when persisting the Parent object. So I suspect I was mistaken about the probable cause of this exception.
Has anyone seen this exception or know what it means?
According to DataNucleus a lot of things are persisted by default... and they even had a complaint in their blog about the manual in the google app engine site, which said that you need to explicitly mark fields as #Persistent.
I figured out what was wrong.
It wasn't complaining about my ArrayList.
My Parent class had an array data member that I hadn't put an annotation on. Arrays are persisted by default in the absence of annotations.
I added the annotation #NotPersistent and this solved my problem.
Related
I am making an MEAN stack app and use Mongoose alongside Mongo. I am struggling with organizing my objects in database. All works as expected but I have a feeling that the way I am doing things is wrong, but can't seem to find any resources on the topic that could help me, thus I hope somebody with some experience can share it with me.
I use Mongoose to create several schemas, and there is one dilemma I am facing, concerning nested objects in MongoDB.
Let's say I have a model that looks like that:
ParentSchema:{
property1:String,
children:[{}]
}
So, property1 is just some string, 'children' is an array that will contain objects of type 'Child' with some other properties, but also another array (f.ex. 'grandchildren:[{]} ), this time with another type of objects (Grandchild).
Child and Grandchild have no schemas and do not exist outside of the Parent, and will most likely be unique to each instance of Parent, so two Parents would not be sharing a Child object.
In my app, I am able to use urls such as '/parent/:id1/Child/:id2/Grandchild/:id3', where 'id1' is an actual id of Parent that Mongo generates, while 'id2' is an index of Child object instance stored in Parents array. The same goes for instances of Grandchildren stored inside Child object.
I was thinking that maybe having separate schemas for all 3 objects, and just saving references to objects is the way to go, like this:
ParentSchema:{
prop1:String,
children:[{type:ObjectId, ref:'Child'}]
}
ChildSchema:{
prop1:String,
granchildren:[{type : ObjectId, ref: 'Grandchild'}]
}
GrandChildSchema:{
prop1:String,
prop2:String
}
..but was unsure, as for me it implies that Child and GrandChild instances would be shared between different parents, however it seems easier to work with.
To sum up, I would like to know is:
which approach should I choose and why: first, second or maybe some other that I do not know about yet.
If I were to choose the second approach, should I create a separate API route for each of the objects?
How would I go about creating then? My wish is for the process to look like so:
Start creating Parent -> start creating first Child -> create some Grandchildren ->
finish creating Child -> start creating second Child -> ... -> finish creating Parent.
I apologize if the question is somehow weird, I will try to clarify as best as I can if required.
I would go with the second approach for a couple of reasons:
Schemas have better readability in my opinion.
They allow for data validation which you lack in the first approach.
Please note the answer below is primarily opinion based.
For the API design:
I think its really up to you as to which paths to expose to the consumer, since you've stated Child and Grandchild do not have the right to exist without a parent - I think your routes are fine as they are.
And finally - your process for creating these entities look fine to me. I would do the same thing myself.
I want to understand the parent/child (ancestor paths) relationship found in the Google AppEngine datastore that wasn't mentioned in the online documentation. What happens to children objects when the parent is deleted? Do child objects also get deleted? Do they become orphaned without a parent? If so how would you query for them?
Google Help Doc regarding Ancestor Paths: https://cloud.google.com/appengine/docs/go/datastore/entities#Go_Ancestor_paths
Thanks!
~Todd
Child entities do not get deleted when the ancestor is deleted: there's no 'cascade on delete' behaviour. In fact, an ancestor entity doesn't even have to exist when defining an entity group (only its Key).
They will remain unaffected, you will just be unable to get their parent entity. i.e.
child_entity.key.parent().get()
will return None.
I am currently learning more about the Google App Engine datastore, and I have some doubts regarding my understanding of the concept of defining a parent key. Now, here's the code for defining a parent key from the GAE documentation:
def guestbook_key(guestbook_name="default"):
"""Constructs a Datastore key for a Guestbook entity with guestbook_name."""
return ndb.Key('Guestbook', guestbook_name)
Note: this code is included in the source code of an application which accepts entries from a user and stores it in a datastore and displays them collectively on the homepage.
Now, this is what I understand from this code(please correct me if my understanding of this concept is not what it is supposed to be):
The 'guestbook_key' function defines a parent key, which we have named as 'default', for all the posts that the user submits into the datastore. So basically, all the posts that are submitted by the user are stored in an entity named 'Guestbook', and we define a key for it's parent(which is non-existent) named 'default'.
Please correct me wherever I went wrong with my understanding.
It really depends on how you use this key. Right now, it is just a name. If you put() it, you are putting a Guestbook type with the name "default".
However, if you are using it as a parent, then you may have code that looks like this:
post = Post(parent=guestbook_key())
post.comment = "This is a new post!"
post.put()
In this case, the new Post object will have the Guestbook object with the name "default" as a parent. Then, you could use an ancestor query to get all Posts for a given guestbook.
The reason you might choose to do this (rather than, for example, have a property on each post with the name of the guestbook) is that it guarantees strongly consistent results. This basically allows all requests to see a consistent view of a guestbook. If you didn't have strongly consistent results, you may see cases where a user writes a post but when they look at the guestbook it doesn't appear.
You are correct that you never actually need to create the Guestbook entity. When you define a parent key, it is actually creating a key where the parent key is a prefix of the child key.
I'm trying to find all object which have no parent (i.e. which were created with parent=None).
Using M.all().filter("parent = ", None).fetch(100) doesn't bring any results, even though some objects certainly do have no parent.
What am I doing wrong?
There's no way to query specifically for root entities. You need to either use external information (eg, no entity of type Foo has parents), or add a property that indicates if an entity is a root entity or not.
You don't use filter() to query for an ancestor. Try instead:
M.all().ancestor(None).fetch(100)
Edit: hmm, that won't work apparently (I'd swear I had done this somewhere). So you'd need to save an extra property as a flag for root entities.
Using parent child relationship where a parent can have children while each child has only one parent, does using Children.all().ancestor(parent.key) a good solution where a child is constructed by setting parent=parent.key in the constructor? Is the 1000 limit applies with this kind of query?
The query returns what you'd expect, all Children which have the specified parent anywhere in their ancestry. The query expresses exactly that, so I doubt there's a simpler way of doing the same thing. But App Engine does keep adding features and surprising me :-)
Possibly you need parent.key(), I think it depends whether you're in Python or Java.
Btw, it's not recommended to use ancestor-parent-child to model relationships in your data. Entity groups exist to enable transactions, not for use as a "free" ReferenceProperty. parent-child should be a low-level implementation detail, meaning either "these two entities may need to be modified in a single transaction", or perhaps "I am playing an optimization trick which allows me to use list properties without having to load the list into memory when I get the entity". As a rule of thumb, if the entities don't all "belong" to the same user, then they shouldn't be parent-child related, because relating them in that way introduces contention when different users try modify them via different datastore nodes:
http://code.google.com/appengine/docs/python/datastore/keysandentitygroups.html#Entity_Groups_Ancestors_and_Paths
Another way to get descendants (children) of a parent entity in Google App Engine that I just discovered:
childrenEntities = db.query_descendants(parentEntity).fetch(1000)
Not sure if it will be helpful to you. It was helpful to me because I was having difficulty figuring out how to access the child class(es) which were created with a python module I installed.
As others have indicated elsewhere, the 1000 limit for everything was removed in February 2010. See the linked blog entry for more details re: this.