Store generated values

Nov 16, 2012 at 12:01 PM


Does Effort have support for "store generated values" (e.g. StoreGeneratedPattern.Computed)?


Nov 16, 2012 at 12:12 PM


Currently it supports timestamp and identity fields. However, supporting all kind of computed fields is problematic, because the EDM metadata model does not contain any information about how the fields should be computed. So a complete support might need some kind of extension point.


Nov 19, 2012 at 3:40 PM


Are you planning to add such an extension point in the near future? If I'm not wrong this should be an NMemory feature.

Best regards,

Nov 19, 2012 at 3:53 PM
Edited Nov 19, 2012 at 3:54 PM

I was thinking about creating a generic extension point that could be used for extending the functionality of Effort. I kindly accept any suggestions about this.. Maybe giving access to the DbSchema class might be enough too.

NMemory has constraints that might serve well for creating computation rules. For example:

var constraint = new ComputeConstraint(
   x => x.ComputedField, 
   x => 2 * x.Field1 + x.Field2);
Dec 7, 2012 at 9:33 AM
Edited Dec 7, 2012 at 7:58 PM

I came up with an idea: the EDMX file is extensible, so it is possible to annotate the storage schema with additional metadata. Take a look at the following example:

   <EntityContainer Name="TestModelStoreContainer">
       EntityType="TestModel.Store.Thing"  />
     <EntityType Name="Thing">
         <PropertyRef Name="Id" />
         Type="int" Nullable="false"
         StoreGeneratedPattern="Identity" />
         Type="int"  />
StoreGeneratedPattern="Computed" effort:ComputeRule="Value1 * 2 + 1" /> </EntityType> </EntityContainer> </Schema>

The effort:ComputeRule attribute value represents how the Value2 field should be computed.  The good thing about this is that this attribute is received by the ADO.NET providers as metadata, so Effort can be informed about this metadata. It is likely that Code First also allows some kind of similar extension point. Do you like this idea?

Dec 7, 2012 at 4:51 PM

Yes, it is a great idea which perfectly suits my needs.

I'm just curious if it would be possible to implement custom computation rules for the value of the effort:ComputeRule attribute?

Dec 7, 2012 at 8:02 PM

What do you mean? Btw I am curious about every scenario that you are planning to cover.

Dec 10, 2012 at 5:08 PM

I was thinking of a situation when the computation rule couldn't be described with a simple equation (e.g. Value1 * 2 + 1). For instance a database trigger may contain quite complex business logic to compute the value of a column,  which couldn't be expressed with a single line computation rule. In those cases it would be very convenient to give the client the possibility to hook into the computation process.

Dec 2, 2014 at 9:02 AM
How would we add a the ComputeRule / ComputeConstraint to Effort in code-first? We have several tables with a Created column which default to GETDATE() / GETUTCDATE().

It was mentioned above that Effort supports Timestamp columns, if we were to use those, how do we indicate to effort that they are of the timestamp type and not datetime?
Jan 5, 2015 at 10:12 PM
Edited Jan 5, 2015 at 10:13 PM
Effort still does not have ComputeRule and ComputeContraint support.

You can check examples for using entities with timestamp.
Jan 30, 2015 at 12:55 PM

Are there any updates for this issue - or is it something in the pipeline?

This project looks really awesome, it's a shame I can't use it due to Computed columns...

In my case I have a not-null nvarchar computed column. For my test scenarios I really don't care about the value of this field as long as it works. However it's not working:
"Column 'x' cannot be null. Error code: GenericError"
I tried supplying the value manually but it gets ignored anyway.
Feb 13, 2015 at 4:25 PM

Not planning to implement this feature in the near future. Sorry.

Are you using DbContext, you may create a workaround with it.
Feb 13, 2015 at 9:46 PM

Thank you for the reply. I'm using a DB-first approach, and yes, the auto-generated models from EF inherit from a DbContext. Are you aware of a possible solution to this? Currently I've placed mocking on hold and went back to actual DB testing, but I would really love to get back to mocking if I'm able to find a reasonable workaround.

Feb 14, 2015 at 11:54 AM
Edited Feb 14, 2015 at 12:54 PM
Basically you have to make the presence of the "Computed behaviour" dependent on the type of the currently used connection object.

This project adds this dependency for "explicitly set column types" (e.g. xml), but the solution to your problem should be really similar.