It all depends on use-case; if it doesn't need high-performance/high-concurrency (which seems unlikely as this is a desktop application) then KISS says use a trigger. You don't even *necessarily* need to requery the DB after an update if this is purely audit information which isn't used in the record create/update part of the application; instead, you can merely create another entity mapped onto the table which doesn't have the properties mapped in code at all, and a separate entity which is used for auditing purposes.
Getting an offset from the DB and then using that (with correction for time changes [either user or automatic] and clock drift at either end) is certainly doable, but it's a significant amount of code to make sure that all the edge cases are handled. Personally, I'd argue that the correct solution depends entirely on the OP's use case but that unless otherwise proven then code simplicity and maintainability are normally much more important than a possibly minor performance gain. From: [email protected] [mailto:[email protected]] On Behalf Of Marios Skounakis Sent: 03 November 2011 07:15 To: [email protected] Subject: Re: [nhusers] Timestamping records in desktop application It's true that there are situations where it may be required or at least safer/easier to user the database. On the other hand there are situations where you want a compromise between accuracy and speed and in this case using the delta between the machine time and the database time is a valid option. A related question is whether NH should provide configurable options on which method to use to set the version property (when it is of type timestamp) (e.g. use DateTime.Now, query the db, use a delta approach). If not, you may have to use a separate DateUpdated property which seems kind of redundant. On Wed, Nov 2, 2011 at 20:44, TheCPUWizard <[email protected]> wrote: David, you raise valid points....First if one uses UTC (as previously suggested) then the non-deterministic order of time is eliminated [just be careful that you don't need historical locals - they are a royal pain] On the security side, you are correct, but I think draw the wrong conclusion. I have done some very high security system (think mil-spec) and having a verification of the time (allowed variance depends on use-case) just like any other piece of data is often preferable to having to round trip every time . -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of David Schmitt Sent: Wednesday, November 02, 2011 6:56 AM To: [email protected] Subject: Re: [nhusers] Timestamping records in desktop application There are legitimate times when the clock goes backwards. DST for one, user error for another, repairing a drifting clock a third. Also, the client cannot be trusted with providing any security-sensitive data since he can easily screw any client-side "security" over thrice by attaching a debugger. So either the timestamps are not security-sensitive after all, then there is no need worrying about them. Or they are sensitive and need to be calculated, written, and protected by an entity not under the influence of the user. In the case that the target environment is so tightly controlled, that the user cannot extract the database connection string and/or password by disassembling the client (soft- AND hardware) you might get away with properly synchronizing client clocks. Since you've asked the question you've asked, I do not think you are in such a situation. D. PS: see http://security.blogoverflow.com/2011/09/storing-secrets-in-software/ for a tangential but related topic. On 02.11.2011 14:27, TheCPUWizard wrote: > Marios, > > Yes there are other considerations for a robust system. But just think > about the implication of a user changing the time on the computer. > Either the original time was wrong or the new time is wrong. But either > can be compensated for by using something (e.g. Stopwatch) which > increments time independently of the system clock once the time has been > dealt with once. > > David > > *From:*[email protected] [mailto:[email protected]] *On > Behalf Of *Marios Skounakis > *Sent:* Wednesday, November 02, 2011 1:18 AM > *To:* [email protected] > *Subject:* Re: [nhusers] Timestamping records in desktop application > > This sounds very interesting. It certainly is efficient. > > One problem is how can you guard against the user changing the machine's > clock time - I think you can subscribe to some TimeChangedEvent and > query the database again... > > On Wed, Nov 2, 2011 at 01:10, TheCPUWizard <[email protected] > <mailto:[email protected]>> wrote: > > Alternatively, just query the database once, set an offset, and be golden. > > *From:*[email protected] <mailto:[email protected]> > [mailto:[email protected] <mailto:[email protected]>] *On > Behalf Of *[email protected] <mailto:[email protected]> > *Sent:* Tuesday, November 01, 2011 2:20 PM > *To:* [email protected] <mailto:[email protected]> > *Subject:* Re: [nhusers] Timestamping records in desktop application > > why not just put them in a trigger in the db? > > On , Marios Skounakis <[email protected] <mailto:[email protected]>> wrote: > > Hi all, > > > > Consider a desktop application in which you want to timestamp records > (store the current date in fields "DateCreated" and "DateUpdated"). > Since it's running on the clients you can't reliably use DateTime.Now as > each client may have a different time, instead you somehow need to get > the database time. > > > > > > Things I have considered: > > 1. Getting the time from the database every time you need it (e.g. > before inserting or updating each record). This can be slow. > > 2. Use an interceptor to get the time from the database at session > flush and update the respective fields for all entities. > > > > 3. Use generated properties. This sounds bad too as it requires an > extra select for each insert/update. > > > > (2) seems to be the best solution. Do people agree? Is there a better > approach for this? > > > > On a related note, if you have a datetime or timestamp version > property, how does NH set its value? In principle, if you have a record > that was just inserted and never updated, DateCreated, DateUpdated and > the version property should all have the same value. > > > > > > Thanks in advance, > > Marios > > > > > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > Groups "nhusers" group. > > > > To post to this group, send email to [email protected] > <mailto:[email protected]>. > > > > To unsubscribe from this group, send email to > [email protected] <mailto:nhusers%[email protected]> > <mailto:[email protected] <mailto:nhusers%[email protected]> >. > > > > > > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > > > > > > > > > > -- > You received this message because you are subscribed to the Google > Groups "nhusers" group. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > To unsubscribe from this group, send email to > [email protected] <mailto:nhusers%[email protected]> > <mailto:[email protected] <mailto:nhusers%[email protected]> >. > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > > -- > You received this message because you are subscribed to the Google > Groups "nhusers" group. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > To unsubscribe from this group, send email to > [email protected] <mailto:nhusers%[email protected]> > <mailto:nhusers%[email protected] <mailto:nhusers%[email protected]> >. > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > > -- > You received this message because you are subscribed to the Google > Groups "nhusers" group. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > To unsubscribe from this group, send email to > [email protected] <mailto:nhusers%[email protected]> > <mailto:[email protected] <mailto:nhusers%[email protected]> >. > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > > -- > You received this message because you are subscribed to the Google > Groups "nhusers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected] <mailto:nhusers%[email protected]> . > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected] <mailto:nhusers%[email protected]> . For more options, visit this group at http://groups.google.com/group/nhusers?hl=en. -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected] <mailto:nhusers%[email protected]> . For more options, visit this group at http://groups.google.com/group/nhusers?hl=en. -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en. -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
