4

Simple, but yet mysterious for me: Why do StringPropertyConfiguration (and all the other PropertyConfiguration) class(es) have 2 overloads for IsConcurrencyToken()?

The first:

public StringPropertyConfiguration IsConcurrencyToken()

Configures the property to be used as an optimistic concurrency token.

And the second:

public StringPropertyConfiguration IsConcurrencyToken(bool?)

Configures whether or not the property is to be used as an optimistic concurrency token.

Why would you use one over the other? As I see it, there's no difference at all between those two overloads (atleast not when working with them)...

By using the first you would write something like:

modelBuilder.Entity<Author>()
    .Property(x => x.Name)
    .IsConcurrencyToken();

And by using the second you would write:

modelBuilder.Entity<Author>()
    .Property(x => x.Name)
    .IsConcurrencyToken(true/false/null);

Have I missed something?

ebb
  • 9,297
  • 18
  • 72
  • 123

1 Answers1

7

My opinion...

The IsConcurrencyToken() defaults to true to provide a simple, fluent manner to define the entity.

The IsConcurrencyToken(bool?) allows the author to definitively set the ConcurrencyMode of the entity. This is useful for advanced scenarios:

  • Overriding the [ConcurrencyCheck] attribute on the POCO
  • Allowing a convention (removed in EF 4.1 RTW) to enable/disable the ConcurrencyMode based on some custom convention

Finally, I think IsConcurrencyToken(false) is better than IsNotConcurrencyToken().

Ed Chapel
  • 6,842
  • 3
  • 30
  • 44
  • 2
    +1 for the "IsConcurrencyToken(false) is better than IsNotConcurrencyToken()". It's the same but reading the second one too fast might make one think that the property IS a ConcurrencyToken (one might just "skip" the "NOT" while reading it fast). – Anderson Matos Jan 23 '12 at 13:59