1:n relation does not validate
Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce 2010
Forum Discription: For .NET 4.0
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=2222
Printed Date: 25-Apr-2025 at 11:34pm
Topic: 1:n relation does not validate
Posted By: mseeli
Subject: 1:n relation does not validate
Date Posted: 11-Oct-2010 at 2:00am
|
In my entity model I defined a 1:n definition between Person and Document A person can have many documents and each document belongs to one person. I try to test it with the following test: [TestMethod] [ExpectedException(typeof(Exception))] public void SaveDocumentWithoutPerson { Dokument newDokument= new Dokument(); newDokument.Id = System.Guid.NewGuid(); // set dokument properties newDokument.ErfasstAm = DateTime.Now; newDokument.MutiertAm = DateTime.Now; Manager.AddEntity(newDokument); // I expected that this would throw an exception Manager.SaveChanges(); } It does not throw an exception and the document without the person ends up in the database! How is that possible? Here the properties of the association (Person is called MasterEntity)  () |
Replies:
Posted By: jsobell
Date Posted: 11-Oct-2010 at 3:58am
|
The EF diagram does not enforce referential rules, and if your Document allows null in the PersonID field then this is presumably going to be allowed. If you generated the EF from the database then you would find that was a 0/1->* If the Document-Person relationship in the database was a foreign key (as it should be in this case) this operation would be invalid and you would at least get an exception from the database. There is another 'funny' with 1->* relationships in DF regarding lazy-loading, so I'm trying to avoid these until they are fixed. I suspect you might hit the same problem when you start retrieving your records. What appears to happen is that if you have a binding to (or you try to read in code) the Document associated with a person, DF creates a 'Pending' Document, then tries to set it's PersonId to the current one. As the Document object is 'Pending retrieval from the database' this raises an internal exception (you can't write to Pending objects), so your app crashes :/ It's weird getting a 'write error' exception on a property Get, but I believe this is being looked into at the moment. I certainly hope so, as it has one of my app developments to a standstill. |
Posted By: kimj
Date Posted: 11-Oct-2010 at 1:07pm
|
Jason, do you have more information on this lazy loading problem you see? In a 1:M relationship, asynchronous navigation from a principal (Person) to its dependents (Documents) will return an empty PendingEntityList and not individual Pending entities. Asynchronous navigation from a dependent to the principal (Document.Person here) should not set any fields on the pending Person entity.
We did have a bug, fixed in 6.0.6, where asynchronous navigation from a dependent to its parent would cause the dependent to go to a Modified state (it's FK property was being result to null/0). Could this be the problem you've seen?
|
Posted By: jsobell
Date Posted: 11-Oct-2010 at 5:18pm
|
Sorry, I got the instamces mixed up. The issue is in 1-1 relationships, where you have a maximum of one Document per Person, and the Document containst the PersonID. PendingEntityLists seem to work fine, but if you have Person.Document as a navigational property referring to a Document with a PersonID foreign key relationship, you get this error. I suppose I could do a workaround by insisting that each person has 'Documents' instead of a 'Document', and always refer to the first instance, although this is messy in the Binding; How would you refer to Binding=Person.Documents[0]? Presumably I have to embed it in a ItemsControl, and assume it only ever has a single item. This may sound an unusual structure, but it occurs every time you have an optional object associated with another object. In my case I have optional 'Target' values associated with a financial object, hence the 1:0-1 relationship with B referring to A rather than vice-versa. I know that A could in theory point to B, but this would require an additional field in A, and we have no control over that database structure. |
Posted By: jsobell
Date Posted: 13-Oct-2010 at 8:10pm
| Guys, can you tell me whether or not this issue has been fixed in 6.0.6? |
Posted By: kimj
Date Posted: 15-Oct-2010 at 12:32pm
|
Sorry to say it has not been fixed.
The problem only occurs when the child's FK is also its PK, but making a modification to the schema likely has other undesirable effects, like the EDM not allowing the relationship.
Although it won't help now, the problem has now morphed slightly. The error now occurs only when the PendingEntity is not found (it doesn't exist in the DB), so what you'd now see is bindings sometimes working and sometimes not, depending on the data.
Unfortunately a bug report was never opened for your earlier query about this issue, but I've opened one now and we will have the problem fixed in one of the 6.0.7 EAP drops.
|
Posted By: kimj
Date Posted: 19-Oct-2010 at 6:15pm
| We fixed this problem (both the original issue and the "morphed" problem) in v6.0.6, which is now available. |