Return nulls when TimeSent is missing

[weralabaj]

Allow for nullable dates (SentTime header) for messages list and failed messages.

[weralabaj]

@johnsimons This is internal change, I think we don't need include it in an announcement, given that we'll provide this information in SP and SI (next version) releases.
SC changes itself don't impact customers directly, only views will be different in SP and SI.

[weralabaj]

That can be released in 1.6. @johnsimons Can I merge it?

[johnsimons]

To me this looks good, @WolfByte thoughts ?

[mikeminutillo]

It looks good to me. My only concern is that any records in the DB which
already have DateTime.MinValue will carry on doing so.

On Tue, 4 Aug 2015 at 16:16 John Simons notifications@github.com wrote:

To me this looks good, @WolfByte https://github.com/wolfbyte thoughts ?

—
Reply to this email directly or view it on GitHub
#491 (comment)
.

[johnsimons]

@weralabaj 👍 to merge

[johnsimons]

Actually we need to talk @weralabaj, hold on the merge

[weralabaj]

@WolfByte the issue was casting to DateTime.Min when results were returned, in db they were still nulls. The only problem might be sagas, but that is out of scope.

[johnsimons]

@weralabaj it looks like u missed more casts:

• ServiceControl/src/ServiceControl/CompositeViews/Messages/MessagesViewIndex.cs

  Line 39 in 84dde51

  TimeSent = (DateTime) message.MessageMetadata["TimeSent"],

• ServiceControl/src/ServiceControl/CompositeViews/Messages/MessagesViewIndex.cs

  Line 62 in 84dde51

  TimeSent = (DateTime) last.MessageMetadata["TimeSent"],

[johnsimons]

@weralabaj can we add an acceptance test as well ?

[weralabaj]

@johnsimons ok I'll revert my merge, sorry for that. Or since it's only impacting sorting (I think) is it ok to fix on develop? I didn't notice any weird behavior when doing manual tests before.

[weralabaj]

@johnsimons Do I understand correctly that both omissions only change the order in which null timesent is treated, e.g. before it was casted to DateTime.Min during sorting, so it was first message in asc order, after making it nullable it'll be the last message in that sort? That's what I managed to reproduce using tests. I don't see any other impact.

[weralabaj]

@johnsimons Daniel said that if we change the types then Raven MIGHT do re-indexing, it depends on how it is implemented. I need to investigate this further, so I reverted the changes from develop.
Apart from Raven forums is there anybody/anywhere I could consult?

[johnsimons]

Daniel and Mauro should be able to help.
Yes, we need to be cautious with reindexing large collections.

On Tue, 4 Aug 2015 at 20:09 Weronika Łabaj notifications@github.com wrote:

@johnsimons https://github.com/johnsimons Daniel said that if we change
the types then Raven MIGHT do re-indexing, it depends on how it is
implemented. I need to investigate this further, so I reverted the changes
from develop.
Apart from Raven forums is there anybody/anywhere I could consult?

—
Reply to this email directly or view it on GitHub
#491 (comment)
.

John Simons
Engineer, Particular Software

Email_:_ john.simons@particular.net karen.fruchtman@particular.net
Web: www.particular.net