EF's blowing in my face



  • Some easy rep to get, since I need the answer for yesterday, and SO folk apparently care more about properly formatting posts than actually answering them:

    http://stackoverflow.com/questions/25960704/failing-check-for-whether-the-object-is-already-tracked

    Some background: it's in the inherited codebase, I don't know shit about how EF works, the code blows up, and Googling for the exception brings up the exact same code that I have in my answer (cheers for your SO searching skills, $previous_dev!).



  • Also, to bring back the funny, just found this question:

    http://stackoverflow.com/questions/25961070/function-passing-in-if-statatement

    Bag bag,
    
    if(bag.IsFull())
            {
                  cout<<"Item can't be placed Bag is full"<<endl;
                  break;            
            }
    
    boolen IsFull()
        {
            return itemcount==MAX_ITEM?TRUE:FALSE;
        }
    

    What is the terminating condition of if loop.I know the function is called by object.what is value bag.full is holding when the condition is false.

    Sometimes I wonder whether SO is one huge test field for ELIZA wannabes.



  • I don't use EF, but from the exception it looks like it's possible for the item to be detached and exist. . . So naive suggestion would be if detached && not exists?

    (Or if you intend to reattach it, if detached . . . if(exists){reattach}else{current set})

    Take with a side of fail.

    POSSIBLY RELEVANT: http://blog.maskalik.com/entity-framework/2013/12/23/entity-framework-updating-database-from-detached-objects/

    With the key appearing to be: _context.Set<T>().Attach(entity);

    (I'd go with @blakeyrat's suggestion, since that's basically what I was trying to say.)



  • To ask the obvious (but not stated in the SO question AFAICT), you have verified that it's not actually a duplicate key?

    Meaning, you've verified that the key you're a duplicate of is identical to the object you're attempting to re-attach?



  • @blakeyrat said:

    Meaning, you've verified that the key you're a duplicate of is identical to the object you're attempting to re-attach?

    The object is supposed to be the same... Then again, some weird shenanigans are going on in here - it just crashed on this line:

    Group attachedEntity = set.Local.SingleOrDefault(e => e.Id == group.Id);
    

    with "sequence contains more than one matching element".

    I think that you might be right - it crashes when creating a new groupMember type-thing, which has a many-to-many relationship with group. Somehow now set.Local contains two entries for each group - an actual group which has the new groupMember added, and a DynamicProxy which doesn't.

    So it seems they differ by the number of groupMembers. Doesn't help that it's all pretty random - I've never got the duplicate entries in set.Local before, only now, and I haven't changed a single line of code.



  • Did somebody change upstream data?



  • That probably could also happen if the Unique constraint is removed from the DB.



  • @Matches said:

    Did somebody change upstream data?

    Oooh, I got the bastard. The data weren't changed per se - they were recreated.

    Instead of getting the groups from the database, it queried for viewmodels, and then copied the viewmodel data into a new group object and new groupMembers inside it, ID included, but some other properties excluded. Then it tried to attach that new object to the context, and Entity barfed, because it already had one from some other query.


Log in to reply