Issue with tracking created and update time.

Hello,

See the attached solution.  When enabling tracking of created and updated times for both the Party and Address models, an exception is thrown when saving changes.  The logs look as follows:

 

SELECT

  KeyTable.NextId AS [KeyTable.NextId]

FROM

  KeyTable

WITH (UPDLOCK)

--> Time:   0 ms

UPDATE

  KeyTable

SET

  NextId = 31

--> Time:   1 ms

INSERT INTO Countries

(

  Id,

  CreatedOn,

  DeletedOn,

  Name,

  OfficialName,

  UpdatedOn

)

VALUES

(

  21,

  '7/2/2011 5:30:55 PM',

  NULL,

  'United States of America',

  NULL,

  '7/2/2011 5:30:55 PM'

);

INSERT INTO Parties

(

  Id,

  CreatedOn,

  DeletedOn,

  UpdatedOn,

  CreatedOn,

  DeletedOn,

  UpdatedOn

)

VALUES

(

  23,

  '1/1/0001 12:00:00 AM',

  NULL,

  '1/1/0001 12:00:00 AM',

  '7/2/2011 5:30:55 PM',

  NULL,

  '7/2/2011 5:30:55 PM'

);

INSERT INTO PersonNames

(

  Id,

  CreatedOn,

  DeletedOn,

  FamilyName,

  GivenName,

  PersonId,

  Prefix,

  Suffix,

  UpdatedOn

)

VALUES

(

  24,

  '7/2/2011 5:30:55 PM',

  NULL,

  'Strydom',

  'Werner',

  23,

  NULL,

  NULL,

  '7/2/2011 5:30:55 PM'

);

INSERT INTO Addresses

(

  Id,

  CreatedOn,

  DeletedOn,

  PartyId,

  UpdatedOn,

  AddressLine1,

  AddressLine2,

  City,

  CountryId,

  CreatedOn,

  DeletedOn,

  UpdatedOn

)

VALUES

(

  22,

  '1/1/0001 12:00:00 AM',

  NULL,

  23,

  '1/1/0001 12:00:00 AM',

  '208 Utah Street, Suite 350',

  NULL,

  'San Francisco',

  21,

  '7/2/2011 5:30:55 PM',

  NULL,

  '7/2/2011 5:30:55 PM'

)

--> Time:   0 ms

System.Data.SqlTypes.SqlTypeException: SqlDateTime overflow. Must be between 1/1/1753 12:00:00 AM and 12/31/9999 11:59:59 PM.

   at System.Data.SqlTypes.SqlDateTime.FromTimeSpan(TimeSpan value)

   at System.Data.SqlTypes.SqlDateTime.FromDateTime(DateTime value)

   at System.Data.SqlClient.MetaType.FromDateTime(DateTime dateTime, Byte cb)

   at System.Data.SqlClient.TdsParser.WriteValue(Object value, MetaType type, Byte scale, Int32 actualLength, Int32 encodingByte

Size, Int32 offset, TdsParserStateObject stateObj)

   at System.Data.SqlClient.TdsParser.TdsExecuteRPC(_SqlRPC[] rpcArray, Int32 timeout, Boolean inSchema, SqlNotificationRequest

notificationRequest, TdsParserStateObject stateObj, Boolean isCommandProc)

   at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnS

tream, Boolean async)

   at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStre

am, String method, DbAsyncResult result)

   at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe)

   at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()

   at ◄.☼.♦.?()

   at ◄.☼.?(IUnitOfWork , IDbCommand , ☺ )

   at ◄.☼.?(IUnitOfWork , IDbCommand )

   at ♦.♠.?(♣ )

   at ♦.♠.?(IEnumerable`1 )

   at ♦.♠.♫()

   at ☼.♠.?(ICollection`1 )

   at ☼.♠.?(UnitOfWorkBase , IEnumerable`1 , IEnumerable`1 )

   at Mindscape.LightSpeed.UnitOfWork.SaveChanges(Boolean reset)

   at LightspeedSample.Program.Main(String[] args) in S:\Projects\LightspeedSample\LightspeedSample\Program.cs:line 43

I would expect it to work like any other entity with these properties set to true.  Any ideas?

Thanks,

Werner

 

 

 

 

This occurs because you have turned on tracking and soft deletion at multiple levels of the hierarchy -- in both the Party and Person entities.  As you can see from the generated code, these options result in extra fields being added to *each* entity (CreatedOn, UpdatedOn, DeletedOn).  When LightSpeed flattens the hierarchy (single table inheritance), the duplicate fields confuse it, and it ends up populating only one of each pair of duplicates.

Obviously, in reality, you don't want or need the duplicates.  Person should inherit its tracking behaviour from Party: it doesn't want or need separate tracking fields.  Similarly GeographicAddress and Address.

So just turn off the tracking and soft delete options at the derived class levels.  These behaviours will be inherited from the base class automatically.

We'll try to update LightSpeed to alert you to this and/or ignore the duplicated fields -- thanks for drawing our attention to this issue!

Thanks,

For usability reasons, I'd rather not see a warning as it is distracting and error prone.   Its also likely to happen frequently when you have large models similiar to this.

I'd also like to add that incorrect migrations are generated for this case.

Werner