Is there a way to create an association in entity framework that always applies a "where" filter?
Here's an example:
Suppose that I have a database that uses "soft" deletes -- so there is a "deleted" column in every table.
So if I have a Customer entity that is related to Address (1:0..n), I would like for the Addresses navigation property to always be filtered on the deleted flag, so that if I go Customer.Addresses, the collection will only return Addresses where deleted == 0.
Anyone know of some way to do that?
No, there isn't.
Same reason you can't have a conditional foreign key.
A workaround could be to use TPH on the Address table:
Create abstract entity called Address
Create derived entities called AddressDeleted and AddressNotDeleted
Set the discriminator mapping (AddressDeleted maps to Address when Deleted = 0)
Create a navigational property between Customer and AddressDeleted.
So when you do ctx.Customer.Include("AddressDeleted").Single() it will only return the addresses that are flagged as deleted.
Or you could defined an association to Address, and use ctx.Customer.Addresses.OfType<AddressDeleted>().
Does that solve your problem?
Related
In SQL, I would tell the database what the foreign key constraint is.
But fluent EF6 apparently does not have a way for me to specify what column to use when binding collections.
Is it not possible to tell DbModelBuilder exactly what column to bind relationships on? Or does it demand to be the primary key at all times?
Table_Person
id int // pkey. Multiple people records
UniqueID int // the unique person
sometext varchar(256) // database therefore tracks changes to this, since unique person can have many records (pkeys).
Table_Address
id int //pkey
fk_unique int // should map to UniqueID of person, NOT the pkey.
line1 varchar(512)
state varchar(64)
etc
One unique person has many records, and their uniqueID (not pkey) has many associated addresses. Actual structure is far more complex than that. But am looking for a way to do this fundamentally...
Would very much so like to have an ICollection<Address> Addresses within the Persons model. But to enable such a thing for code-first migrations... seems impossible?
Yes I could Add-Migration and then modify the generated code/sql manually. But doesn't that defeat the point? Or is that common practice?
If you're able to modify the DB schema you could put UniqueIDs for people into their own table named "Person" and rename the existing table to "PersonVersion". Then have FKs to the new "Person" table on "PersonVersion" and "Address". And finally, create the Person, PersonVersion, and Address models in your app code and EF should bind without problem.
I am creating a new database using EF code-first which contain the following classes:
Address, Contact, Account, Customer (a sub-class of Account), and SalesOrder.
The Address class is the one giving me problems at the moment, it can have no foreign key because it can be linked to any of the other five classes (with more to come), and each of the other classes can have one or more navigation properties pointing back to it.
The navigation properties should look as follows:
Contact.AddressId?
Contact.Address
Account.AddressId?
Account.Address
Customer.DeliveryAddresses
SalesOrder.InvoiceAddressId
SalesOrder.InvoiceAddress
SalesOrder.DeliveryAddressId?
SalesOrder.DeliveryAddress
It should be possible for these classes to share the same Address record, e.g. an Account has an Address, this can also be linked to a SalesOrder, a different Address, linked to the Customer, could be linked to another SalesOrder. All Addresses linked to Accounts and Customers should be unique, but other classes should be able to share links to these Addresses.
I have tried setting it up with all the possible fluent configurations I can think of, with my DbContext having a DbSet property and without (ultimately I don't think it should have it's own DbSet property, as the Addresses should only be accessible from the various root objects, but if that's the only way to get it to work I'm happy to manage the inserts/deletes myself).
I tried making all the navigation properties nullable (ideally SalesOrder.InvoiceAddressId should not be nullable), and also had to remove the Customer.DeliveryAddresses Many-to-Many mapping at one point because that was confusing the issue.
I get various errors depending on how I have it set up, either Multiplicity conflicts due to non-nullable fields, or Cascade on Delete errors when I have no DbSet property and I try and let EF handle the inserts and deletes.
I also end up with unwanted null rows when I do have a DbSet property set. e.g:
add three Address records to the DbSet (Address(1), Address(2), Address(3),
add two Accounts to the DbSet (Account(1) & Account(2)),
add multiple SalesOrders,
set Account(1).AddressId = 1
set Account(2).AddressId = 2,
set SalesOrder(n).InvoiceAddressId = 1,
set SalesOrder(n).DeliveryAddressId = 3
This will correctly create the Address records, but the related keys will only be set correctly if the various Id foreign-key properties are used, rather than the navigation property, and even if the Id properties are used the foreign keys all look correct, but orphaned records for each SalesOrder (or two per order if both navigation properties are used) end up in my Address table with all their fields bar Id set to NULL.
The only thing I can think of that I haven't tried would be to create multiple sub-classes of Address and use each one with it's related class (e.g. SalesOrderDeliveryAddress), but that doesn't seem ideal. I'd rather not do that unless I have to.
Is what I'm looking for possible to set up in EF, or is there some other way to go about doing it?
Thanks,
David
There are several issues making this confusing. To start with I would switch off the default cascade on delete to get rid of multiple cascade paths and come back to that later.
Then read about adding disconnected trees, foreign keys and navigation properties here: http://msdn.microsoft.com/en-us/magazine/dn166926.aspx
Then I would set up the entities you way you want them and repost a more specific issue. (You have tried lots of stuff so it's hard to work out what happens when here)
Once you've got adding and updating working you can come back and work out where you can put in cascade delete and where it needs to be manual
I have couple of questions with update functionaliy using NHibernate
I have Customer and location entities with 1:n relationship. Customer has location property. While creating/updating customer entity, I just assigned location property and commited changes.
new Location() { Id = ViewModel.LocationId };
Is it proper way to do it or do I need to retrieve the location entity from db and attach it again like below
newCust.Location = GetlocationfromDB(ViewModel.LocationId);
And how does it work with m:n relationship. I have order and orderitems entities. So, if a newgroup is added/deleted, do I need to check which group is added and get from db and attach it or just groupid will do fine..
This isn't the right way to do it - it might work if you have your unsaved-value mapping right for the primary key, but the proper way to do it is to use session.Load(ViewModel.LocationId) see http://ayende.com/blog/3988/nhibernate-the-difference-between-get-load-and-querying-by-id
There are a number of ways of dealing with this, but it sounds like you want your relationship to be mapped as a set (to prevent duplicates) rather than a bag. If you map it as a set and use ISet for the property type of the relationship, the duplicates will be handled for you. If however you use a bag, you would need to remove duplicates in your own code. Again, you should be using session.Load to get the group if it's an already existing group.
I have 2 tables:
orders
orderItems
connected to one another threw a relationship(FK orderId in the orderItems table). is there a difference between:
order.orderitems.remove(...)
to just setting the orderId value to null when trying to remove the related entity?
Setting the FK property to null and removing the entity from the navugation property both do the same thing. That is, they both sever the relationship between the entities but do not cause either entity to be deleted. It's the same as setting the FK value in the database to NULL.
To delete the entity you must call Remove on the DbSet for the entity. For example
context.OrderItems.Remove(orderitem);
context.SaveChanges();
I have 2 entites:
Im my DB they look like:
Vehicles(Id, VehicleNumber, IsDeleted, WorkerId)
Workers(Id, Name, Address)
And in my edmx:
VehicleId: Id, VehicleNumber, IsDeleted, WorkerId, Worker
Workers: Id, Name, Address, VehiclesList
As you can see, Vehicles table contains soft deleted rows. Now when I get Worker with id=2, I got all his vehicles, including the one I soft deleted. How can I retrieve only the undeleted vehicles?
Badly. EF has very limited support for soft deletes. Actually the only possibility is using conditional mapping where you explicitly hardcode (it cannot be changed at runtime) to your mapping condition saying that you don't want to load entities having IsDeleted = 0. Check mapping details:
But it has very bad consequences:
IsDeleted column cannot be mapped - it already defines mapping internally
Your model can never be used to load soft deleted entities even if you want
The first problem can be solved by mapping stored procedure to delete operation for the Vehicle entity and the second problem can be solved by separate model for auditing and retrieving deleted entities.
Also conditional mapping is not supported by code first - it requires EDMX file.
is lazyloading enabled? then try to limit result set with a where:
worker.VehiclesList.Where(x=>!x.IsDeleted)
also you can put a condition to a vehicles table mapping in model desiner isdeleted = false. Soft deleted vehicles will not be retrived at all