I've got
class Parent
{
IList<Child> Children;
}
class Child
{
}
When deleting a Child I need to remove all references to it from any Parents that reference it.
How can I do this in NHibernate?
There is no Parent FK on Child, the relationship is stored in a 3rd "link" table
Thanks
This is not a parent-child relation. Children have only one parent (the belong to the parent). This is a many-to-many relation between independent entities. This is a important difference.
You can't actually remove the "children" from the "parent" directly in HQL the way it is designed now. This are your options:
load the "parents" into memory and remove the "child" from the list.
Add a reference from the "child" back to the "parents". Make the other relation inverse. It should actually automatically remove the item in the link table when you remove a "child", because the link would belong to the "child" then.
Delete the link using native SQL. This is not nice, but also not too bad because it is trivial standard sql.
To make this happen, there needs to be a relationship of some sort, starting from the Child Entity.
Then you can simply use cascade-delete to its 3d (I'm guessing this is a many-to-many) table.
Related
I'm working on a project in ASP.NET MVC 5, with ADO.NET EF to generate data from the SQL server. I have several one-to-many relationships in the database. When I fetch data and project it to a local variable, e.g. var query = model.listFromDbChildTable.ToList(); where model.listFromDbChildTable is just entities loaded from the db. This is the lowest table in the relationship hierarchy.
So the thing is, and I am not sure why, every time I go to "locals" in VS, in debug mode, I can go deeper and deeper into my relations, for example, I am looking at a child table (department), and when I go to this child in locals, I see child has a relation with parent (above it), s I go to parent table, (I believe this is normal,) but when I'm at parent (table), again I can go to child table from there, and I am not going up one step back in the hierarchy, but so to say deeper, like a stair down all the time. So I go again to child, and child can go to parent again, every time with the same element. And I can redo this process many times?
So what is going on? Are my relations wrong or is this some normal procedure with locals in VS?
The following image shows two tables that participate in one-to-many relationship. The Course table is the dependent table because it contains the DepartmentID column that links it to the Department table.
Basically any link between two entities can be explored(Table in SQL ,class in EF)
In SQL you refer just a column in child table as key whereas in entity a property is create which has type of a class .
Like in below example, Course will have property name "Department" of type "Department" class as it depends on it (also a DepartmentId property).
you can read more in detail here on msdn..and Don't worry moving from SQL to Entity framework does give you small suprises :) .Hope it helps.
Parent Child Entity MSDN
According to the SQLAlchemy docs:
The one case where SQL is not emitted is for a simple many-to-one
relationship, when the related object can be identified by its primary
key alone and that object is already present in the current Session.
For this reason, while lazy loading can be expensive for related
collections, in the case that one is loading lots of objects with
simple many-to-ones against a relatively small set of possible target
objects, lazy loading may be able to refer to these objects locally
without emitting as many SELECT statements as there are parent
objects.
Assume that:
A Parent can have many Child, while a Child has only one Parent.
Parent has a relationship children = relationship('Child', back_populates='parent', lazy='select')
parent_0 is an instance of Parent and child_0, child_1 are instances of Child, whose parent is parent_0.
If I've understood it correctly, this means the first time I access parent.children, SQLAlchemy would check the local identity map for related objects (i.e. Child instances referencing parent_0), and would query the database if nothing is found.
My question is, how does it know which Child instances are related to parent_0 without querying the database? Even if all Child instances have been loaded to the local identity map, this only means "all Child instances can be accessed through their primary keys without having to query the database", or alternatively "given a specific primary key, it can return a Child instance without having to query the database". The problem is, without querying the database,how does SQLAlchemy know what the primary keys of the related objects of parent_0 are?
If it don't know, then I can't understand how loaded Child instances can help to bypass the database query.
SQL Query
select * from zchildren where zparent = 3586 OR zparent in (Select zid from zchildren where zparent = 3586)
I have tried few cases with $SUBQUERY but Still i am not getting any success. So how can i achieve this ?
Update
I have Table Name which is Children which has Parent which contains the ID of the same table ID , Its a Inverse Relationship now i want All the children which parent is '3586' and its all sub children
Update2
I am Attaching the screen shot
Now Few more points
Table Group has One-To-Many Relationship with Children
Table Children has Two Relationship
First which is Inverse to Group One-To-One
Second children relation which is Inverse to itself which is called Reflexive
Updated Question
Now suppose i have one Query i want to search from Children table where title is 'Medical' AND Parent is '3586'
Now This '3586' is parent id which is coming from Table Group And i can easily predicate this .
Problem
It Gives me children whose parent '3586' but i also want to search in the title of sub-children which are Reflexive of this parent ID , Means sub-children of children which came from parent '3586'.
I really need this solution. I can still update my question if any one is not clear in this question.
When tackling somewhat complicated Core Data issues, you really have to be a bit more accurate. Your code and your variable names are sloppy and wrought with mistakes.
In your SQL query you have an attribute parent (or "zparent"), but in the Core Data model it becomes an attribute rather than a relationship. (Were you perhaps thinking of modeling ids? That would indicate that you are still trapped in relational database thinking and have not fully grasped the concept of the object graph yet. Forget about ids and think in relationships instead.)
You need a reverse relationship to children, so this cannot be the same relationship. Calling the entity "Children" is confusing because 1) you are using the plural for a singular object and 2) you are calling both parent and children "Children". You also misspell "Children" as "Childran", potentially leading to all sorts of errors.
Instead, let me suggest the entity name Person. A person can have one or more parents (or is it only one?) and one or more children both of which are also of type Person, resulting in a many-to-many relationship:
Person - parents <<----------------->> children - Person
If a person can only have one parent it if of course a many-to-one relationship.
Person - parent <------------------->> children - Person
You can then fetch a Person with idNumber 3586 (notice that using id is perhaps also a bad idea as it is a reserved word in some contexts). You can then access that person's children very succinctly:
person.children
That's really all there is to it.
I am trying to optimize a tree-structure for my category-model. The Category-model has a Parent-property and a Children-collection.
The way i normally do this, is to load all categories (sounds bad, but max 100 nodes). The tree is then manually assembled, by indexing all categories by id, and then by looking up the parent by the categories parentid. Dirty but really quick. The problem i have, is that i dont know how to get/map the ParentID from the parent-relation when using nhibernate.
Say i have this mapping in fluent nhibernate:
References(cat => cat.Parent,"Parent_id")
.FetchType.Select()
.WithForeignKey("Category_ParentCategory");
My question is then: How can i get or map the parentid on a given category, without loading the Parent from the database?
And also, has anyone a practical experience in mapping trees, or tried http://blogs.hibernatingrhinos.com/nhibernate/archive/2008/05/14/how-to-map-a-tree-in-nhibernate.aspx?
You can map the ParentId as a property in addition to mapping the Parent object. You will probably want to map ParentId as read only and put logic in the setter for Parent to set ParentId.
However, this may not be necessary. If you're populating the tree in a single ISession then each Parent will only be loaded from the database once and retrieved from cache on subsequent requests.
What is the parent and what is the child in a sql relationship?
In my case, I have a part (Say screw), and product material. For argument's sake, a product material (eg steel) can only belong to one part (but not in the real world). So this is 1:n. The part will have its pk as a fk in the ProductMaterial table.
Which is parent and which is child in this case?
Relational databases such as SQL actually have no concept of parent/child relationships - that is an interpretation that you as a programmer put on the data. There are architectures that explicitly state and use such relationships, such as heirarchical (and to a certain extent OO) databases.
You can interpret a 1:n relationship in database this way: A child is always that model which holds the foreign key as this indicates where it belongs to.
Of course if you have self referencing models/tables you have to look at it in a different way.
In this case, Part is parent and ProductMaterial is child.
A parent can have unlimited numbers of children (scary thought - 2 is enough for me!), whereas a child can have only a limited number of parents - and in DB terms, only 1!
Usually in a one-to-many relationship, it's the "one" record that is the parent, and the "many" records that are the children.
Of course, in some cases it doesn't make any sense to talk about a parent-child relationship. In your example it makes some kind of sense at least. In other examples you may even find the opposite, where a child has many parents, but then it's not very useful to describe it that way.
Another way to look at this, in addition to what David M. said, is in terms of an ORM implementation (such as Linq to SQL). You have two entities, Part and ProductMaterial. Each part entity has a set of ProductMaterial entities (children entities or an EntitySet). Each ProductMaterial entity has zero or one Part entity (parent entity or an EntityRef).
Randy
I would say that any table which has a one to many relationship with one or more other tables can be considered a parent to those other tables. Self joining? An ambiguous term which I don't think anyone understands.
'Product' is parent and 'Product material' is child in Product_ProductMaterial relationship or association.
If you delete a child, parent can live and continue life. If you delete parent, child become orphan or identityless which is not good. If A can not not be deleted before B is deleted, then A is parent and B is child.
If I guess right, in your case in Product_ProductMaterial relationship, if you delete Product, ProductMaterial will be assigned to no one, become orphan, identity crisis. But if you delete ProductMaterial, Product can still be there, no need identity support.
Sorry if my wordings are not good.