Probably the last sentence isn't correct in the link I sent you (sorry for that 
- didn't read it carefully enough).

Similar docs can be found here
http://knol.google.com/k/fabio-maulo/nhibernate-chapter-16-improving/1nr4enxv3dpeq/19#16(2E)5(2E)(C2)(A0)Understanding_Collection_performance
with a slightly different text for one shot delete, which makes more sense I 
think.


________________________________
Från: [email protected] [[email protected]] för Dzyann Leleur 
[[email protected]]
Skickat: den 4 april 2011 23:35
Till: [email protected]
Ämne: Re: [nhusers] Delete Cascade taking a long time

Hi Fabio, thanks again for your answer.
What you say comes handy, I will work that way.

I am creating the db using Nhibernate, and everything is working fine, but 
deletion, which actually works, it just takes a long time, since is not doing 
one shot deletions. I am going to try using "on-delete="cascade" and if it 
doesn't work well I can try the second approach you mention.

Anyway in my previous mail, my question was not regarding this 2 methods, 
because I havent tested them yet.
Was regarding using what is recomended on the documention:
18.5.4. One shot delete
That is not very clear, it says that by clearing the collection of elements, 
the items should be deleted in one shot (list.Clear())
And it mentions:
one-shot-delete apply to collections mapped inverse="true".

That is the first answer I got, and I tried to implement it and it didn't work, 
from what Roger says, and what i could see on internet, actually putting 
inverse="true" won't allow it work. So i am not sure if I am not understanding 
the documentation, or maybe it is wrong.

Regards,

Dzy.-

On Mon, Apr 4, 2011 at 6:21 PM, Fabio Maulo 
<[email protected]<mailto:[email protected]>> wrote:
ehm... are you creating the DB using NH ?
are you validating the schema using NH ?
on-delete="cascade" works as espected but you have to check what NH think you 
have in the DB with what you really have;
also you have to check the <cascade> configuration because even when you have 
the ON DELETE constraint (hard cascade) the delete operation may become 
"inefficient" due soft-cascade (logic cascade).
in practice... if you have on-delete="cascade" and you are 100% that the child 
entity does not have any other soft-cascade with others entities, on delete, be 
sure that your <cascade> value does not includes neither "delete" nor 
"delete-orphans".

btw
session.CreateQuery("from Child c where c.Parent.Id<http://c.Parent.Id> = 
:theParent").ExecuteUpdate();
do the same work you done with Ado.NET

On Mon, Apr 4, 2011 at 5:45 PM, Dzyann Leleur 
<[email protected]<mailto:[email protected]>> wrote:
Hi Roger, thanks for your answer.

That the parent know its children so far has been relevant for the deletion 
case, which is needed. Now i do Understand if you guys consider this shouldn't 
be handled by Nhibernate. That is why I sent an email here. I have all the Web 
Application working with Nhibernate, and when I found this problem, the easiest 
solution for me was just to use ado.net<http://ado.net>, that is why in my 
initial email I asked if the best would be an approach like just do the sql 
sentence (ado.net<http://ado.net> or such).
I asked help here because I wanted to try keep all the application using 
Nhibernate, but if for cases like this doesn't make sense, is fine.

I read what you said about the inverse=true, but I have certain confusion with 
it.
On the link you gave me ( 
http://www.nhforge.org/doc/nh/en/index.html#performance-collections-oneshotdelete)
  says:
one-shot-delete apply to collections mapped inverse="true".

Now from what I have been reading on internet this doesn't work, It actually 
behaves like you say. So maybe the documentation is wrong? or i just totally 
misunderstood what it says?

Regards,

Dzy.-



On Mon, Apr 4, 2011 at 4:52 PM, Roger Kratz 
<[email protected]<mailto:[email protected]>> wrote:
<<I am not going to perform operations like you put, for each item of the 
collection, we are just doing queries over them.>>

Instead of letting the parent knows thousands of children, isn't enough if the 
child knows its parent?


Anyhow....

Having inverse=true means that this side doesn't own the collection. AFAIK, 
this means that theCollection.Clear() won't do anything from a NH perspective.

Try hql delete, plain ado.net<http://ado.net> or, as already mentioned, 
on-delete="cascade".



________________________________
Från: [email protected]<mailto:[email protected]> 
[[email protected]<mailto:[email protected]>] för Dzyann Leleur 
[[email protected]<mailto:[email protected]>]
Skickat: den 4 april 2011 20:04
Till: [email protected]<mailto:[email protected]>
Ämne: Re: [nhusers] Delete Cascade taking a long time

Hi,
The Domain, is designed as it is, is a very specific case, that doesn't happen 
much. And actually, is just an applicatin to migrate data, so the user doesn't 
have this problem of having such massive associations.

I am not going to perform operations like you put, for each item of the 
collection, we are just doing queries over them.

What I want to know if the way I set the deletion was correct.
This is what i have (without the on-delete="cascade")

<hibernate-mapping xmlns="urn:nhibernate-mapping-
2.2" default-access="property" auto-import="true" default-cascade="none" 
default-lazy="true">
 <class xmlns="urn:nhibernate-mapping-2.2" mutable="true" name="Query, Domain, 
Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" table="`Query`">
   <id name="Id" type="System.Int32, mscorlib, Version=4.0.0.0, 
Culture=neutral, PublicKeyToken=b77a5c561934e089">
     <column name="Id" />
     <generator class="identity" />
   </id>
   <bag cascade="all-delete-orphan" inverse="true" name="NasLocations" 
mutable="true">
     <key>
       <column name="Query_id" />
     </key>
     <one-to-many class="NASLocation, Domain, Version=1.0.0.0, Culture=neutral, 
PublicKeyToken=null" />
   </bag>
   <bag cascade="all-delete-orphan" inverse="true" name="MetadataItems" 
mutable="true">
     <key>
       <column name="Query_id" />
     </key>
     <one-to-many class="MetadataItem, Domain, Version=1.0.0.0, 
Culture=neutral, PublicKeyToken=null" />
   </bag>

Mapping for QueryMetadataItem and NasLocations relation with Query:

<many-to-one class="Query,Domain, Version=1.0.0.0, Culture=neutral, 
PublicKeyToken=null" foreign-key="Query_id" name="Query">
     <column name="Query_id" />
   </many-to-one>

I am deleting the items as follows:
query.NasLocations.Clear();
query.MetadataItems.Clear();

And then removing the Query itself.
The NasLocations items do not get deleted at all, and the MetadataItems get 
delete one by one.

I did this following the link Roger gave me. I don't see what I am doing wrong.

Regards,

Dzy.-


On Mon, Apr 4, 2011 at 2:48 PM, Fabio Maulo 
<[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
 wrote:
public class Country
{
...
...
public IEnumerable<Person> People{get; private set;}
}

using(var session = sf.OpenSession())
{
  var china = s.QueryOver<Country>().Where(x=> x.Name == 
"China").SingleOrDefault();
  foreach(var person in china.People)
{
 DoSomethingButComeBackTomorrowToSeeResult();
}
}

The link that Roger gave you is correct what is incorrect is the design of the 
domain.

On Mon, Apr 4, 2011 at 2:33 PM, Dzyann Leleur 
<[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
 wrote:
Hi Fabio,
What do you mean with that trying to map a collection that big is wrong? Do you 
mean like I shouldn't use NHibernate? Or that the collection shouldn't be that 
big?
The collection is being created by a service, we don't have a choice but having 
that collection, there is no other way. The service is not working with 
Nhibernate to create the data. We are using Nhibernate for the User interface 
part, that creates queries on the data. But has the option to delete them too.

When I saw how Nhibernate was behaving, I thought that maybe I shouldnt try to 
delete the collection with Nhibernate and just do it with SQL, but I wanted to 
see different options.
I am going to try the "on-delete="cascade"", but, was the approach I 
implemented following the link:
http://www.nhforge.org/doc/nh/en/index.html#performance-collections-oneshotdelete
that Roger gave me, wrong?

Regards,

Dzy.-

On Sun, Apr 3, 2011 at 10:04 PM, Fabio Maulo 
<[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
 wrote:
try to map a collection with 95K items is simple wrong and nothing more.
btw you can use on-delete="cascade"


On Fri, Apr 1, 2011 at 6:23 PM, Dzyann 
<[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
 wrote:
Hi,

I have a an entity Query that has a lot of items Metadata in a
relation "one-to-many".
When I delete the Query, I want all its childs to be delete too, so I
set cascade to all-delete-orphan.

The items get deleted, but it takes a lot of time. The query can have
many items, lets say 95k items.
I checked out with the SQL Profiler to see what was going on, and I
saw that each Metadata Item is getting deleted one by one like:

exec sp_executesql N'DELETE FROM MyDatabase.dbo.[QueryMetadata] WHERE
Id = @p0',N'@p0 int',@p0=302401

This takes time, and produces a bad user experience. I would like to
hear out any recommendations.
Maybe is better if I delete the items with a sql sentence?

Thanks in advance for your help!

Dzy.-

--
You received this message because you are subscribed to the Google Groups 
"nhusers" group.
To post to this group, send email to 
[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>.
To unsubscribe from this group, send email to 
[email protected]<mailto:nhusers%[email protected]><mailto:nhusers%[email protected]<mailto:nhusers%[email protected]>>.
For more options, visit this group at 
http://groups.google.com/group/nhusers?hl=en.




--
Fabio Maulo


--
You received this message because you are subscribed to the Google Groups 
"nhusers" group.
To post to this group, send email to 
[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>.
To unsubscribe from this group, send email to 
[email protected]<mailto:nhusers%[email protected]><mailto:nhusers%[email protected]<mailto:nhusers%[email protected]>>.
For more options, visit this group at 
http://groups.google.com/group/nhusers?hl=en.


--
You received this message because you are subscribed to the Google Groups 
"nhusers" group.
To post to this group, send email to 
[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>.
To unsubscribe from this group, send email to 
[email protected]<mailto:nhusers%[email protected]><mailto:nhusers%[email protected]<mailto:nhusers%[email protected]>>.
For more options, visit this group at 
http://groups.google.com/group/nhusers?hl=en.



--
Fabio Maulo


--
You received this message because you are subscribed to the Google Groups 
"nhusers" group.
To post to this group, send email to 
[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>.
To unsubscribe from this group, send email to 
[email protected]<mailto:nhusers%[email protected]><mailto:nhusers%[email protected]<mailto:nhusers%[email protected]>>.
For more options, visit this group at 
http://groups.google.com/group/nhusers?hl=en.


--
You received this message because you are subscribed to the Google Groups 
"nhusers" group.
To post to this group, send email to 
[email protected]<mailto:[email protected]>.
To unsubscribe from this group, send email to 
[email protected]<mailto:nhusers%[email protected]>.
For more options, visit this group at 
http://groups.google.com/group/nhusers?hl=en.

--
You received this message because you are subscribed to the Google Groups 
"nhusers" group.
To post to this group, send email to 
[email protected]<mailto:[email protected]>.
To unsubscribe from this group, send email to 
[email protected]<mailto:nhusers%[email protected]>.
For more options, visit this group at 
http://groups.google.com/group/nhusers?hl=en.



--
You received this message because you are subscribed to the Google Groups 
"nhusers" group.
To post to this group, send email to 
[email protected]<mailto:[email protected]>.
To unsubscribe from this group, send email to 
[email protected]<mailto:nhusers%[email protected]>.
For more options, visit this group at 
http://groups.google.com/group/nhusers?hl=en.



--
Fabio Maulo


--
You received this message because you are subscribed to the Google Groups 
"nhusers" group.
To post to this group, send email to 
[email protected]<mailto:[email protected]>.
To unsubscribe from this group, send email to 
[email protected]<mailto:nhusers%[email protected]>.
For more options, visit this group at 
http://groups.google.com/group/nhusers?hl=en.


--
You received this message because you are subscribed to the Google Groups 
"nhusers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/nhusers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"nhusers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/nhusers?hl=en.

Reply via email to