New Posts New Posts RSS Feed: 1:n relation does not validate
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

1:n relation does not validate
 Post Reply Post Reply
Author
  Share Topic Share Topic  Topic Search Topic Search  Topic Options Topic Options
kimj View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 09-May-2007
Posts: 1391 		Post Options Post Options   Quote kimj Quote  Post ReplyReply Direct Link To This Post Topic: 1:n relation does not validate
    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.
Back to Top
kimj View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 09-May-2007
Posts: 1391 		Post Options Post Options   Quote kimj Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
jsobell View Drop Down
Groupie
Groupie
Avatar

Joined: 02-Apr-2009
Location: Australia
Posts: 80 		Post Options Post Options   Quote jsobell Quote  Post ReplyReply Direct Link To This Post Posted: 13-Oct-2010 at 8:10pm
Guys, can you tell me whether or not this issue has been fixed in 6.0.6?
Back to Top
jsobell View Drop Down
Groupie
Groupie
Avatar

Joined: 02-Apr-2009
Location: Australia
Posts: 80 		Post Options Post Options   Quote jsobell Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
kimj View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 09-May-2007
Posts: 1391 		Post Options Post Options   Quote kimj Quote  Post ReplyReply Direct Link To This Post 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?
Back to Top
jsobell View Drop Down
Groupie
Groupie
Avatar

Joined: 02-Apr-2009
Location: Australia
Posts: 80 		Post Options Post Options   Quote jsobell Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
mseeli View Drop Down
Newbie
Newbie
Avatar

Joined: 20-Sep-2010
Location: Switzerland
Posts: 31 		Post Options Post Options   Quote mseeli Quote  Post ReplyReply Direct Link To This Post 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)


()
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down