I started learning PHPCR with doctrine in Symfony-CMF, and I have a question.
Is that possible to have #Children and #Child on 2 differents attributes of the same document ?
According to the doc...
The annotated instance variable will be populated with Documents directly below the instance variables document class in the document hierarchy.
I think that there should be only one #Children or #Child per document. But how to manage forms if there's different documents into the same attribute ? It's not clear for me the usage of this. Should I choose one attribute whith #Children & #ReferenceOne / #ReferenceMany on the others ?
PHPCR is a tree, every node is located under its parent. For the parent, that is a child node. When using #Child, you adress one specific child with a field. Using #Children, you map all child documents and the member variable having this mapping contains a collection. note that there is a middle ground: you can specify to filter #Children by a naming pattern of the children.
indeed you can end up with the same child in #Child and #Children - we recommend to not inline the editing of an unfiltered children collection, but make that links. if you have a filtered children collection and a separate child, things can work out nicely.
references are cross-links not following the tree hierarchy. they are less efficient than parent-child relations. you should only use those for secondary relations, but keep your primary content structured in the tree.
Related
I have an Elastic Search mapping with parent and child documents. It can be one-to-many but I have only created one-to-one relationship between a parent and child. Reason for this relationship instead of nested documents is that children are updated frequently and I can avoid touching parent documents everytime. This would avoid creating deleted documents of parent doc type which is taking 70% more space than required before merge happens.
Now I have a query which returns a list of parent documents. But I also want to retrieve all children for that parent list.
Is it possible to get all parents and associated children with the same query instead of running a separate query to get children of each parent?
I'm looking for some help with ElasticSearch involving multiple "parent" types sharing the same "child" type.
As a trivial example, let's say I have two parent types:
blogEntry
status
I'd like to have a single "comment" type which is a child of both "blogEntry" and "status", since users can comment on both blog entries and users' status updates.
Is this actually possible in ES?
Or, am I looking at this problem in the wrong way? Does parent-child make no sense here, and instead would I want to use nested objects?
Thanks!
This is not possible at the moment:
The parent child mapping does not allow to specify multiple parents
Lets say if you have 2 parents which are routed to different shards,
which shard will the child document be routed to?
You could instead have one child as nested document to the parent and the more frequently changing one as an actual child referencing the parent type.
I've read the docs and I cannot seem to figure out how to structure my GraphQL for a particular query. For my data I have:
child
|_ school
|_ class
A child has schools and schools have classes, but a child is only assigned to specific classes in a school.
I want to query a specific child to get only the classes they are in.
query={
child(id:$id){
schools{
name
classes{
name
}
}
}
}
I can technically filter the classes while resolving the schools field in the child type by looking deep down the fields but I wanted to clarify that this is still conforming to GraphQL. Should I be placing the classes as a field in the child type instead?
A child also have classes, so it makes sense to create a classes field in the child object. This, in addition to the classes field in the school object.
Of course you could also filter the classes while resolving it but it's just another extra work with no particular reason.
Since there is a direct relationship between a child and his classes it seems better for a child to have a classes field.
I have an entity(ex: Document) that is used as child in 4 other entities(using #OneToMany with #JoinTable in parents). I am not using Bidirectional Mapping. My requirement is to remove the Child(i.e Document), and I have two ways to do that, one way is, get the 4 parents, remove child from them and update them. Second, using native query(using jdbcTemplate) to remove entry from 4 join tables and remove the child.
Is there any other way it can be done in much simpler manner?
Create an abstract base class containing the Document as member and user JPA inhertiance --> http://en.wikibooks.org/wiki/Java_Persistence/Inheritance
Than it should be possible to get all users of a document with just one query.
Than it should be relatively easy to remove all references.
Don't do magic behind automatic deletion stuff. Thats for the cost of documentation.
Add orphan deletion (ie. delete child object when it's removed from collection in the parent). To enable it, you need to add
#OneToMany(orphanRemoval=true)
in owning entity.
Parent & Child objects are being stored in different shards
Here is how I'm implementing the Parent and child objects.
I've custom routing parameter for my parent object.
Parent ID is specified while adding child object.
If there is no custom routing parameter, everything works just fine. But if I specify custom routing parameter to my Parent object, child objects are not stored in same shard, which is causing the search queries to fail.
Is there a way to fix the issue without forcing the custom routing value on Child ?
I'm using ES 1.0 Beta2 version .
Thanx
By default the parent document uses its _id as the routing value, and the child document uses the value of parent as its routing value. The value of parent is the same as the _id of the parent, so they end up on the same shard.
If you use a custom routing value on the parent, then you need to specify it on the child as well, eg:
PUT /myindex/parent/1?routing=custom_val
{...}
PUT /myindex/child/2?parent=1&routing=custom_val
{...}
An alternative is to use an alias with a configured routing value:
PUT /myindex/_alias/myalias
{ "routing": "custom_value" }
Then you can index into the alias instead, without specifying the routing on every request:
PUT /myalias/parent/1
{...}
PUT /myalias/child/2?parent=1
{...}