I understand datastore works like a file system but it seems it doesn't behave like a file system.
Given the parent kind "parent" and child(current) kind "child" a query on "parent" kind alone(not the complete key) fails to return any result. Why is that if it's like a file system?
I see the hierarchy like this: /parent/parentKeyID/child/childKeyID. Is it wrong?
Related
I tried to create a simple interface for building a gedcom compatible text file using C#.NET.
I am stuck with proper FAM record creation (I mean, something is logically wrong in my code). I believe that tester.cs has a complete information of grandfather, father, self, spouse, child1, and grandson relationships.
Is is possible to correct the gedcom output, without making significant changes in the tester.cs?
May be you need to fork the entire source code. The software produces gedcom.ged file, which should be loaded in Simple Family Tree 1.32 to see that the gedcom is valid.
Currently, I ended up with the funny and unusual relationships as in the picture.
Grandfather should have married to grandmother, and "self" needs to have a child, giving a grand child to grand father. Gotra's spouse should be null (unmentioned). And like that...
Probably I should fix something in individual.cs.
Your help is kindly expected. PS: I am also working to resolve the issue, and the source code may change a bit. Thanks in advance!
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.
As part of a testing utility I am creating some registry keys and applying a specific security descriptor to them. Later on I want to reset it to the "default" security descriptor (i.e. inherited from the parent). What is the proper way to do this?
I can't save and restore the original security descriptor because this utility may be run multiple times before the tester will want to reset it. I guess I could save it to a temp file or registry value, but I would prefer a more elegant solution.
So, do I have to do something with the parent's security descriptor or what? I'm having a hard time figuring out what to do.
Almost forgot to mention I'm doing this in C.
UPDATE: I should have added that I'll also be doing this with files (and possibly other securable objects), so it would be nice if there were a generic way to work with security descriptors themselves instead of using object-specific things like RegSaveKey. I imagine it would require working with the security descriptor of the parent, so it would be great if I could do something like the following:
BOOL WINAPI GetDefaultChildSecurityDescriptorFromParent(LPSECURITY_DESCRIPTOR Parent, LPSECURITY_DESCRIPTOR* Child);
I'm just not sure how to do it programmatically. You can accomplish this in the security descriptor editor by using the check box to inherit entries from the parent, so obviously it is possible somehow.
I recommend saving keys to a file using RegSavekey. To restore the key use RegLoadKey.
The easiest way I can think to do this would be to read in the structure that needs to be defaulted... then delete it and recreate it - passing NULL to force the defaults.
I hate to answer my own question, but I found a snippet of documentation on the matter (the DACL is really the only thing I am concerned with). Looks like I have to get the DACL of the parent and create a new DACL that includes all the inheritable ACEs in it. I was hoping it would be simpler than that, but it's not too bad.
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.