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]> wrote:

Alternatively, just query the database once, set an offset, and be golden.

 

From: [email protected] [mailto:[email protected]] On Behalf
Of [email protected]
Sent: Tuesday, November 01, 2011 2:20 PM
To: [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]> 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].
> 
> 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.

-- 
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.

Reply via email to