Hello. Here's a schema with Company, Account and Order tables. A Company is 1:N with Account and Account is 1:N with Order. There is a UC on Account.Name. Using v1.0.2004.2 and self-servicing I was trying to create a new order for a new account:

AccountEntity ae = new AccountEntity();
ae.Company = _company;
ae.Name = "Smith";
OrderEntity oe = new OrderEntity();
oe.Account = ae;
ae.Save(true);

The problem is that if the UC is violated once, then it becomes impossible to create new accounts; that violation keeps happening indefinitely on every save. I figured the problem is in using the same _company entity instance so I fixed it by changing line 2 above with this:

ae.CompanyID = _companyID;

The global _company entity doesn't need to be updated, so it doesn't need to participate in the recursive save, but I would expect that when Save doesn't succeed for whatever reason, the operation should totally rollback and clean up all participating entities. Is that a wrong assumption?

obzekt wrote:

Hello. Here's a schema with Company, Account and Order tables. A Company is 1:N with Account and Account is 1:N with Order. There is a UC on Account.Name. Using v1.0.2004.2 and self-servicing I was trying to create a new order for a new account:

AccountEntity ae = new AccountEntity();
ae.Company = _company;
ae.Name = "Smith";
OrderEntity oe = new OrderEntity();
oe.Account = ae;
ae.Save(true);

The problem is that if the UC is violated once, then it becomes impossible to create new accounts; that violation keeps happening indefinitely on every save. I figured the problem is in using the same _company entity instance so I fixed it by changing line 2 above with this:

ae.CompanyID = _companyID;

The global _company entity doesn't need to be updated, so it doesn't need to participate in the recursive save, but I would expect that when Save doesn't succeed for whatever reason, the operation should totally rollback and clean up all participating entities. Is that a wrong assumption?

It will roll back all modifications in the database, not in the entities. So if you RE-save the same account, without changing its name, you again will get the same UC violation, because the value 'Smith' is apparently already taken.

I understand that if I save the same account I will get the same UC violation. The problem is that even if I save another instance of account entity, with a new name that doesn't exist in the DB, the previous UC violation on 'Smith' kicks in because of _company, even if _company itself hasn't changed. In other words, it seems that the unrelated _company instance caches the UC violation of another object (account). This doesn't seem correct.

obzekt wrote:

I understand that if I save the same account I will get the same UC violation. The problem is that even if I save another instance of account entity, with a new name that doesn't exist in the DB, the previous UC violation on 'Smith' kicks in because of _company, even if _company itself hasn't changed. In other words, it seems that the unrelated _company instance caches the UC violation of another object (account). This doesn't seem correct.

If you do: newAccount.Company = _company;

the newAccount object is added to _company.Accounts, but the OLD one is still there, in that same collection. Now, when you're saving newAccount, _company is also examined. It's not dirty so not saved, but it relates to another account object which is not saved yet, so that's saved as well.

To fix this: either remove the old violating account object from _company.Accounts or set the Company property of that account object to null.