Best Practices for Default Field Values

Discussion of open issues, suggestions and bugs regarding LinqConnect – Devart's LINQ to SQL compatible ORM
Post Reply
jeffs
Posts: 7
Joined: Fri 15 Oct 2010 13:42

Best Practices for Default Field Values

Post by jeffs » Wed 20 Apr 2011 16:06

What are the best practices for creating default values for fields in a table?

(Basically, handling the existence of default values set in the database, or overriding such behavior at runtime.)

There are two kinds of default values I mean:

1. The value to provide without any user interaction (default creation timestamps and the like)

2. A default value to put in a NEWed up object, but which can be overridden by the user before saving.

I'm eager to learn if there is a tried-and-true approach I'm not seeing.

StanislavK
Devart Team
Posts: 1710
Joined: Thu 03 Dec 2009 10:48

Post by StanislavK » Thu 21 Apr 2011 14:03

1. To use the default value provided by the database (e.g., timestamps with the current date/time), you can set the 'Auto Generated Value' property of the corresponding entity field to true, and ensure that no IdGenerator is set for this column. In this case, the LinqConnect runtime will send no value for this column to the server, and will retrieve the value generated by the database instead.

2. The literal specified in the 'Default Value' property of entity field is used to set the value of this field on entity object creation. If this field was not changed, 'Default Value' is sent to the database when persisting the entity. This scenario works only in case 'Default Value' can be parsed as a literal of the corresponding data type; otherwise, the field will be initialized with the default value of this data type. This behaviour was implemented in the latest 2.50.22 Beta build only. You can download this build from
http://www.devart.com/dotconnect/oracle/download.html
(the trial version) or from Registered Users' Area (for users with active subscription only):
http://secure.devart.com/

Post Reply