Last days I've been wondering why there's no transaction on a deleted root and its children.
I put the TransactionalAttribute on the Update methode my ObjectFactory, where the 3 cases (insert/update/delete) are handled and it worked perfectly for insert but not for deferred deletion.
I debugged through CSLA's DataPortal and recognized that the actual check for deferred deletion is if there's an TansactionalAttribute on a Delete(myObject) method on the ObjectFactory, but later on the Update(myObject) is invoked.
Now, after I added a (dummy) Delete(MyClass obj) along with a TansactionalAttribute all works fine.
Q: Is this by design? And if so, why / what's the intent?
(and I looked through the DataAccess ebook but couldn't find this.)
Which version of CSLA do you use?
Seems to be a bug! DataPortal should check for Transactional attribute on the method it actually calls.
This is true for version 4.0 - 4.2.
Within the Server.DataPortal:
{
....
if (factoryInfo != null)
{
....
if (bbase != null)
{
if (bbase.IsDeleted)
methodName = factoryInfo.DeleteMethodName;
else
methodName = factoryInfo.UpdateMethodName;
}
...
method = Server.DataPortalMethodCache.GetMethodInfo(factoryType, methodName, new object[] { obj });
....
context.TransactionalType = method.TransactionalType;
....
result = portal.Update(obj, context)
}
Using the Encapsulated Invocation or Implementation, you'll have indiviual DataPortal_Insert/Update/Delete/DeleteSelf methods, where you can put Transactional Attributes on them as you like.
Using the ObjectFactory you only have Update, (immediate) Delete and Execute for commands. So, the DataPortal is not that fain-grained, which machtes the "in ObjectFactory you do all by yourself". Except this confusing discrepancy of Update / Delete method for the attribute.
However, if this is choosen to handle immediate and deferred deletion the same, that would be a good point, too. Then, I'm missing a note in an ebook (in a next revision) mentioning this.
Copyright (c) Marimer LLC