looking at an existing NHibernate implementation that maps a single class to two database tables that are joined. The current functionality is read-only. The table join is actually hidden away via a readonly view and it's the view that's referred to in the NHibernate mapping. Works fine for readonly behaviour. Except I need to add Insert, Update, Delete behaviour and only one of the tables needs to be inserted/updated/deleted. How best to do this? I can take readonly off the view of course, I could replicate the join in the NHibernate mapping, but how do I tell NHibernate that insert/update/delete affects one table only?
Thanks DC
You can set the update and insert attributes on the property mappings to false and they will be excluded from updates and inserts:
<property name="MyProperty" update="false" insert="false" />
Keep in mind that your view will need to have a single primary key defined to enable updates or inserts.
You can map to a view instead of a table, then define custom sql for your inserts, updates and deletes.
I would recommend calling a stored procedure.
See the docs: http://nhibernate.info/doc/nh/en/index.html#querysql-cud
I've used this technique quite a lot and it works fine.
Related
Here's my problem: I have a set of ids. These are the ids of a collection of root entities. Now I want to delete all these root entities, efficiently.
I can't do a WHERE Id IN (1, 2, 3) type of clause, as I'm deleting root entities with children.
I'm wondering if it's possible to avoid retrieving all root entities and deleting them one by one. The problem with that approach isn't so much the SELECT, it's have lots of separate DELETE statement.
Is it possible for NHibernate to batch this, including the delete of all the children? Extra complexity: children can have their own children.
So I'd want NHibernate to first delete the 'bottom-most' children with an IN-clause (maybe multiples ones), then the children with an IN-clause, and then finally the root entities with an IN-clause.
If this isn't possible, what's a good approach to delete multiple root entities efficiently with NHibernate?
UPDATE
This is not valid in your case where you had a list of ids (didn't read your question properly).
First, batch deletes of the "parents" can be made setting adonet.batch_size, http://nhibernate.info/doc/nh/en/index.html#performance-batch-updates.
END UPDATE
Secondly, to avoid reading the children (and generate deletes for these), you can set the cascading delete to happen on db level by setting ON CASCADE DELETE as a foreign key constraints.
Eg (note the on-delete attr)
<set name="TheCollection" inverse="true" cascade="save-update">
<key name="theKey" on-delete="cascade"/>
<one-to-many class="TheType"/>
</set>
Note that
this only works on inverse (bidirectional) relationships.
your db schema needs to be updated with this fk constraint
don't use cascade="all" or similar where deletes are included
Might help using the Session.Delete statement passing an array of IDs? I believe this will delete the whole map for those objects matching the IDs in the array.
Session.Delete("from MyTable t where t.ID in :IDs", IDs, NHibernate.NHibernateUtil.Guid);
where IDs is an array of Guids in this case, but could be any object.
Suppose I have a class Foo. I also have a view on Foo called Foo_Foo that lists a many-to-many association between Foos. I mapped this association as a simple immutable set on each Foo, with cascade="none":
<set name="association" table="Foo_Foo" cascade="none" mutable="false">
<key column="ParentFoo" />
<many-to-many class="Foo, MyAssembly" column="BaseFoo" />
</set>
However, when I try to delete a Foo, NHibernate tries and rightly fails to delete the Foo.association.
How can I prevent NHibernate from trying to delete the association to a view?
The collection belongs to Foo. You can't share the collection, so there is no need to keep it in the database. Cascade is used to tell NH if the referenced Foos should be also deleted or not.
Why do you want the Foo_Foo records to keep in the database? If this should be a bidirectional many-to-many self reference, it doesn't work like this.
Edit, after understanding the question.
Cascade doesn't work in your case, because it affects only the referenced Foos.
To avoid inserts / updates and deletes of the collection table, you may try one of the following:
First obvious attempt is mutable="false", which you already tried. I don't really understand why it isn't working. You may ask in the Nhibernate user group.
Less obvious, but promising is inverse="true". Inverse tells NH that the collection is mapped somewhere else and doesn't need to be stored from here. So it just omits inserts, but I don't know about deletes.
If this doesn't work, you need to explore more complex solutions. You could map it as a one-to-many of an intermediate entity which references the Foos. The intermediate entity is a mapping to the view. It is immutable (which still may lead to delete statements). In this case, cascade="false" will work (because it is the referenced entity). It will also work configure insert, update and delete sql statements (which are empty), but this is most probably not even necessary.
I have an object hierarchy as follows:
Object
Reports
Report Items
Based on other posts here, I set the Report.ReportItems mapping to Inverse, and CascadeAllDeleteOrphan. This makes it so when I remove a Report from an Object it goes to erase the ReportItems in that report.
The way it does it is very inefficient. It basically does a Delete ... Where ReportItemID = ?.
I've seen suggestions to increase the batch size to prevent this from being done in too many round trips, but that seems like a sloppy fix. Is there a way to make NHibernate generate a query like this instead:
Delete ... Where ReportID = ?
This way it would execute one query that would delete all the ReportItems instead of one statement per ReportItem.
Thanks in advance.
Edit
I have heard from a few people that NHibernate will simply not work this way with standard QueryOver etc.
I decided to start using HQL to fix the problem. I will later use some reflection to make sure there are no "magic strings" being used.
I had the idea to:
Use HQL to mass-delete the Report Items
Tell the Session to Refresh the object so it could detect that the Report Items are gone
Then tell the session to erase the Report, and let it clean up the remaining information
This does not work though. You can see the code below:
Session.CreateQuery("delete ReportItem r where r.Report= :report").SetEntity("report", SelectedReport).ExecuteUpdate()
Session.Refresh(SelectedReport)
Object.Reports.Remove(SelectedReport)
Session.Delete(SelectedReport)
Session.Update(Object)
I have also tried doing a Session.Evict after performing the HQL statements, but NHibernate keeps using the cache to try to delete the ReportItems. Any tips on how to do this?
If your foreign key has delete rule set to cascade then you can tell NH not to generate DELETE statements for child items when the parent is deleted. In this case NH will generate DELETE statement only for parent entity.
<bag name="ReportItems" cascade="all-delete-orphan" inverse="true">
<key column="report_id" on-delete="cascade" />
<one-to-many class="ReportItem" />
</bag>
After a lot of research I have found that this is simply not possible. You can use HQL, raw SQL statements, or rely on database rules to perform the deletes by enforcing a relationship. However, there is no way to tell NHibernate to delete a list of objects based on their owner's ID.
Let's say we have two entities, A and B. B has a many-to-one relationship to A like follows:
#Entity
public class A {
#OneToMany(mappedBy="a_id")
private List<B> children;
}
#Entity
public class B {
private String data;
}
Now, I want to delete the A object and cascade the deletions to all its children B. There are two ways to do this:
Add cascade=CascadeType.ALL, orphanRemoval=true to the OneToMany annotation, letting JPA remove all children before removing the A-object from the database.
Leave the classes as they are and simply let the database cascade the deletion.
Is there any problem with using the later option? Will it cause the Entity Manager to keep references to already deleted objects? My reason for choosing option two over one is that option one generates n+1 SQL queries for a removal, which can take a prolonged time when object A contains a lot of children, while option two only generates a single SQL query and then moves on happily. Is there any "best practice" regarding this?
I'd prefer the database. Why?
The database is probably a lot faster doing this
The database should be the primary place to hold integrity and relationship information. JPA is just reflecting that information
If you're connecting with a different application / platform (i.e. without JPA), you can still cascadingly delete your records, which helps increase data integrity
In EclipseLink you can use both if you use the #CascadeOnDelete annotation. EclipseLink will also generate the cascade DDL for you.
See,
http://wiki.eclipse.org/EclipseLink/Examples/JPA/DeleteCascade
This optimizes the deletion by letting the database do it, but also maintains the cache and the persistence unit by removing the objects.
Note that orphanRemoval=true will also delete objects removed from the collection, which the database cascade constraint will not do for you, so having the rules in JPA is still necessary. There are also some relationships that the database cannot handle deletion for, as the database can only cascade in the inverse direction of the constraint, a OneToOne with a foreign key, or a OneToMany with a join table cannot be cascaded on the database.
This answer raises some really strong arguments about why it should be JPA that handles the cascade, not the database.
Here's the relevant quote:
...if you would make cascades on database, and not declare them in
Hibernate (for performance issues) you could in some circumstances get
errors. This is because Hibernate stores entities in its session
cache, so it would not know about database deleting something in
cascade.
When you use second-level cache, your situation is even worse, because
this cache lives longer than session and such changes on db-side will
be invisible to other sessions as long old values are stored in this
cache.
In my application users cannot truly delete records. Rather, the record's Deleted field gets set to 1, which hides it from selects.
I need to maintain this behaviour and I'm looking into whether NHibernate is appropriate for my app. Can I override NHibnernate's delete behaviour so that instead of issuing DELETE statements, it issues UPDATES, as described above?
I would obviously also need to override its SELECT behaviour to include the 'AND Deleted = 0' clause. Or read from a view instead. I'm not sure.
To implement a soft delete just bypass the Hibernate delete mechanism. Instead, map your table's Deleted field to a .Net boolean property by the same name. To delete an item, set item.Deleted = true. Then add a where attribute to your class mapping to filter out the deleted items. If you like, create another mapping for deleted items. Otherwise they will become invisible to your application, but maybe that's what you want.
Edit: Here is perhaps a better approach: use the <sql-delete> tag to write a custom delete operation for your mapping. See http://docs.jboss.org/hibernate/core/3.3/reference/en/html/querysql.html#querysql-cud. I think this in combo with the where attribute would be just the ticket. For example:
<class name="MyClass" table="my_table" where="deleted=0">
...
<sql-delete>UPDATE my_table SET deleted=1 WHERE id=?</sql-delete>
</class>
I implemented this using INSTEAD OF DELETE triggers on SQL Server to set a delete flag bit when a SQL DELETE is issued. This has two benefits: 1) I can just issue deletes from my app. without worry and 2) It enforces soft deletes for all database access (i.e. the trigger must be temporarily disabled to hard delete). I then set up views that select the active records only and mapped NHibernate to those. This solution has worked very well for me.
I think the best way to get such behaviour would be by implementing the IInterceptor interface which would allow you to perform your own code as shown within the NHibernate Documentation.
Otherwise, you could simply create a trigger on delete that would perform an update. This solution is simpler, but is this suitable for your needs?
As for the SELECT, you only need to write method that will use Criterion with a Where clause to specify the Deleted=0 thing.