This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi there, I've been having difficulties removing an entity. We have an Account entity, based on an Account database table, and a SalesSummary entity, based on a vwSalesSummary view. The view contains extended information about the account, and the table and view share an Id. That is, the Id column of the view is taken from Account.Id, and there is a foreign key attribute in the SalesSummary entity that points the association at the Id field of Account. The problem I'm having is in removing an Account. To avoid going into too much detail, I've isolated this in some test code:
|
|
|
Despite my careful formatting, the example code in my post is all over the place!!! Here's a link to a .txt file with the code in: http://www.edwardsmale.co.uk/removing-an-entity-that-has-an-associated-view.txt |
|
|
And just in case you can't read the tiny text, here's the problem: Whether or not there is a corresponding row in the view, a NullReferenceException is thrown on the call to SaveChanges() when the SomeTable is removed.I wondered for a while whether it's to do with LightSpeed trying to delete the associated SomeView entity, in a kind of cascading delete mechanism, but I've tried all the attributes I can think of on both ends of the association, and nothing so far has worked. Any ideas what I can do to get around this problem? Thanks, Ed |
|
|
We'll take a look at this, but for the time being I think you can work around it by replacing the EntityHolder associations with lookups. Since the foreign key is the ID, the relationship is immutable, so the fact that you lose the tracking features and foreign key management provided by associations doesn't matter -- and the fact that you lose the cascading delete is a positive benefit. So try changing it to something like this: public class SomeTable : Entity<int> { and similarly for SomeView.SomeTable. FindById looks in the UOW's identity map before going to the database so this is still efficient. The downsides of this approach are: * Can't traverse the association in queries. E.g. you won't be able to use Entity.Attribute("SomeView.SomeField") when querying for SomeTables. * Can't eager load, so there could be a N+1 problem if you load lots of SomeTables and then use all of their SomeViews. |
|
|
Thanks Ivan, that approach is working well for what we are doing at the moment. As you say, it is limited in that you can't traverse the association in queries; this could be a problem at some stage but we'll cross that bridge when we come to it. We created the view for performance reasons, and currently all the columns we need are included in the view, so there isn't any need to do a JOIN from the table to the view through LightSpeed at the moment. Thanks Ed |
|