Enhanced CreatedOn, UpdatedOn and DeletedOn

It's great that you handle these datetime columns automatically.  Why stop there?  It would be great if you also provided tracking for what function and user did the CRUD operation.  They would be strings and not validated.  Their defaults values could be provided when the context is created and then overridden by a unitofwork if necessary.  If you think that is too many fields, then have them just once and they would apply to the CRUD operation that occurred last.

The legacy application I'm looking at rewriting using LightSpeed has these fields (single occurrance).  I'll have to add all this logic myself unless you'd do it for me.

Thanks.

Interesting idea Steve. We've been pondering adding some form of audit logging to LightSpeed (currently pegged for after LightSpeed 3.0) but this could be a nice start. We've discussed some fairly involved capabilities around auditing but this probably the most simply approach we've had suggested. Unfortunately we're unlikely to add this in the near term because of our LightSpeed 3.0 commitments but it's certainly on our minds. I appreciate any further thoughts you have around this as it just helps the depth of our discussion on the feature. Thanks, John-Daniel Mindscape

Wow, I really need to fix these forums so they don't lose formatting when posting from Safari. Sorry about that.

Yes, this is a very simple approach to logging.  That's why I was hoping you could get it into 3.0.  How about 3.0.1?

Just to pitch in, to some extent you can do this yourself without having to write logic in too many places -- in particular you can get away without having to write logic in the application code.

You will need to create the properties / columns yourself, though you can do that in a base class so you only have to do it once.

The trick then is to override OnSaving (possibly also in the base class) to set the user name column.  You could use the entity state to determine whether this was a create or an update.

This does have some limitations -- in particular when we "save" a pending delete we do not post any changed data back, we just issue a DELETE or update the DeletedOn column, so you would not be able to track who performed a delete this way.

In terms of capturing which function performed the create or update, that is a little bit trickier.  Obviously by OnSaving this information is long since gone.  However you might be able to get somewhere by overriding OnPropertyChanged and capture the info from there.  (If it was strictly important to know which function issued the new() call, you could also override Initialize(), but be careful, as this is called for all entities, including those being materialised from the database.)  You might actually get better results than a generic implementation, as you could make more intelligent judgments about what was the "business meaningful" function (as opposed to say some low-level repository method).

You might also find the thread at http://www.mindscape.co.nz/forums/Thread.aspx?ThreadID=1739 useful, though a lot of this thread is devoted to issues around creating and saving separate "log record" entities which would not be an issue in your approach.