Dieter Maurer wrote:
You should be happy about the much more explicit information.
It may allow you to analyse your problem better.
This question has nothing to do with that problem, it just came up as a
result of once again being reminded that we use timestamps as
transaction ids.
For
Chris Withers wrote:
Dieter Maurer wrote:
You should be happy about the much more explicit information.
It may allow you to analyse your problem better.
This question has nothing to do with that problem, it just came up as a
result of once again being reminded that we use timestamps as
Dieter Maurer wrote:
Chris Withers wrote at 2006-10-5 09:52 +0100:
...
I'm wondering why we take on those issues rather than just use an
incrementing integer sequence instead?
With integer keys, you would not be able to pack to something
like n days before -- as you do not have any time in
Jim Fulton wrote at 2006-10-5 13:58 -0400:
...
With integer keys, you would not be able to pack to something
like n days before -- as you do not have any time in your
storage file
You would still need to track times, but you could manage
this as transaction meta data, rather than using it
...
[Chris Withers]
Yes, but using timestamps also means:
- we're dependent on the system clock being accurate for no good reason
[Jim Fulton]
I'm hoping that Jeremy or Tim will chime in, since we considered switching
to integers a while back.
Not much to say here. It's not true that
Chris Withers wrote at 2006-10-4 09:45 +0100:
...rather than just incrementing integers?
I'm asking 'cos I've just started having time-stamp reduction errors
on a production system where a contingent system is having a .fs file
that's been re-constituted from repozo backups tested with
