Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > LLBLGen Pro Runtime Framework> UC violation on recursive Save
 

Pages: 1
LLBLGen Pro Runtime Framework
UC violation on recursive Save
Page:1/1 

  Print all messages in this thread  
Poster Message
obzekt
User



Location:

Joined on:
29-Apr-2004 18:18:59
Posted:
49 posts
# Posted on: 25-Oct-2005 16:46:00.  
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:

Code:
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:

Code:
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?
  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37869 posts
# Posted on: 26-Oct-2005 10:32:33.  
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:

Code:
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:

Code:
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.


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
obzekt
User



Location:

Joined on:
29-Apr-2004 18:18:59
Posted:
49 posts
# Posted on: 31-Oct-2005 12:53:30.  
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.

  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37869 posts
# Posted on: 31-Oct-2005 14:40:05.  
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.


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.