The ORM Foundation

I've been using nORMa and I've been very happy with the tool and its SQL script generation.  I was excited to see that it generated a WCF service to generate Linq to SQL, but I was disappointed that the service does not function.  The contract being generated is incorrect.  Example is below:

#region Insert, Select, Update, and Delete Operations for Customer
[OperationContract(IsOneWay=true)]
[TransactionFlow(TransactionFlowOption.Allowed)]
void InsertCustomer(Customer customerToInsert);
[OperationContract(IsOneWay=false)]
Customer SelectCustomerByCompanyName(String companyName);
[OperationContract(IsOneWay=false)]
Customer SelectCustomerByPreferredIdentifier(Int32 customerId);
[OperationContract(IsOneWay=true)]
[TransactionFlow(TransactionFlowOption.Allowed)]
void UpdateCustomer(Customer newCustomer, Customer oldCustomer);
[OperationContract(IsOneWay=true)]
[TransactionFlow(TransactionFlowOption.Allowed)]
void DeleteCustomer(Customer customerToDelete);
#endregion // Insert, Select, Update, and Delete Operations for Customer

This contract is not correct.  The only allowed TransactionFlow option with a one way contract is TransactionFlowOption.NotAllowed.  I'm not sure if there is a configuration option to correct this or if it is a problem with the code.  Any assistance would be appreciated.

Temporary workaround, I've asked Jaron (you designed this transform) to comment as well. 

In the meantime, it looks like the UseTransactionScopes option is not in the settings schema file or fully implemented in the transform. Add the UseTransactionScopes='false' option to the ServiceLayer element in the settings file, then save, right click the .orm file, and choose 'Run Custom Tool' to force the file to regenerate.

-Matt

I tried this, but it does not appear to have any effect.  The same code is produced.  The top portion of the file is as follows;

<ConnectionString DataSource="devtablet" SettingsProperty="" DatabaseName="MyDb" />
<!--Change basic name generation settings-->
<NameParts />
<!--Change WCF name generation settings-->
<ServiceLayer UseTransactionScopes='false' />

Ideally, you wouldn't want the transaction scope to be changed, as it is preferable to use a transaction when conducting insert and update operations.  Instead the operations should not be implemented as one way.  Normally I would return a success indicator back to the application and specify IsOneWay=false on these operations.

-John

Geez (directed at myself, not you), the XSLT to read the two boolean settings (there are only two of them) is garbage. If the attributes have any value then they will always be true.

You'll need to change the default in the XSLT.

1. C:\Program Files\Common Files\Neumont\ORM\Transforms\LinqToSql\DcilToLinqAttributeMapping.xslt
2. Look for @UseTransactionScopes in the file
3. 6 lines later you'll see a true(). Change it to false()
4. Remove the attribute you added before from the settings file

Apologies on this, the service layer code is incomplete and should have been turned off.

I'm not a WCF expert by any stretch, but it sounds like you are. Any suggestions on things you think we should change would be much appreciated.

-Matt

I’ll make the changes.  Actually I will also remove the IsOneWay=true specification for the contract. The server side code actually seems to work perfectly if you set the transaction scope in the contract or change the IsOneWay to false.  The idea here is to allow a transaction to be transferred from the client to the service.  If the code is executed from a workflow for example, you might be committing several calls within a single transaction.  Without it you can still use server transactions.   

The following blog entry gives a good description of when to use the IsOneWay=true setting.  Typically it is to optimize in cases where success notification (or rather exceptions) are not something you are concerned about.  If you have IsOneWay=true, the connection is disengaged immediately after the call, thus any exceptions that occur will not be propagated back to the client.  This should be used very sparingly.  Even if the return type of the method is void, you can still have the IsOneWay=false so that exceptions can be propagated back to the client.  This is also why transactions cannot be flowed to these methods, as any transaction rollback cannot be indicated back to the client.  It looks like it was assumed that any void method should be one way, which is not the case.

 

It would probably be good to include a OptimizeOperationalMethods attribute that would indicate whether the IsOneWay should be set to true, but the default should be false.  Even when doing a one way contract, I will set the IsOneWay to false during debugging, but if I truly needed them optimized, it would be nice to have the option.  If I were importing in batch for example, I would probably rather log issues and do each as a separate transaction (or no transaction at all) rather than send errors back to the client.

 

-John

 

Actually, the original syntax is correct.  It defines the attribute with a default of true.  It does a test to see if the setting is present, and sets the result of a test to see if it was set to true.  If the setting was present and set to false (or anything other than true or 1), the "$setting='true' or $setting='1'"  test will return false. 

The issue is actually later in the XSLT where it is testing the resulting value.  This test is done as if the variable were a boolean.  Since it is a string, you actually have to test to see if it is true ($UseTransactionScopes='true')  rather than just use the variable.

I added parameters for OptimizeOperationalMethods and UseTransactionFlow.  TransactionFlow is determining whether the client transaction flows to the method whereas TransactionScope determines if the method is done in the context of a transaction.  Even if you are not using the client transaction you may want to use transactions, so I thought it was prudent to separate the two.  The OptimizeOperationalMethods works as discussed.  Also, if OptimizeOperationalMethods is set transaction flow is turned off regardless of the setting.

You can't attach files here, but I uploaded the updated xslt to the library.