Hi,
There is some chatter on this list regarding new projects using Magma.
To prevent duplication and despair I have attached the extensions to Magma that I use to index UUID and DateAndTime instances.
Indexing UUIDs ----------------- MaUUIDIndex will index any UUID and has a keySize of 128 bits. This it because a UUID is 16 bytes long.
Indexing DateAndTimes -------------------------- A DateAndTime instance includes the offset from UTC and has nanoSecond precision. It can also store any date since 24 November -4713.
Indexing a full DateAndTime would require a LOT of bits, which is probably why Chris never added an index for them.
Fortunately, we do not need a) to store dates all the way back to the dawn of time b) nano second precision c) to store dates infinitely far into the future.
MaDateAndTimeIndex allows the developer to specify: a) the start epoch (dates on or before this are not allowed) b) the clock precision (one of 1 second. 1 milliSecond, 1 nanoSecond) c) the duration into the furture (ie. epoc + duration = last date which is allowed)
The default has a keySize of 72 bits and gives nanoSecond precision from 1 January 1900 for 1000 years!
I usually use:
(MaDateAndTimeIndex attribute: #dateOfBirth) epoch: 2000 asYear; duration: (100 * 365.24) days; precision: 1 second; yourself
which gives a keySize of 32 bits.
Feedback welcomed.
Chris, if you like this work, feel free to modify it and add it to Magma.
Regards
Brent
Hi, I have already added a UUID index to be included in the next major release (real soon now). I will, however, plan to add your DateAndTime index. Thanks!
Indexing DateAndTimes
A DateAndTime instance includes the offset from UTC and has nanoSecond precision. It can also store any date since 24 November -4713.
That is quite amazing.
Indexing a full DateAndTime would require a LOT of bits, which is probably why Chris never added an index for them.
Ahem. Actually, I haven't had time to purge my rudimentary Ma time objects yet. I *do* plan to do that when I get time. Chronology looks fantastic, if a bit heavyweight on DateAndTime (but now I understand why, stretching nanosecond precision so far forward and back).
Fortunately, we do not need a) to store dates all the way back to the dawn of time b) nano second precision c) to store dates infinitely far into the future.
MaDateAndTimeIndex allows the developer to specify: a) the start epoch (dates on or before this are not allowed) b) the clock precision (one of 1 second. 1 milliSecond, 1 nanoSecond) c) the duration into the furture (ie. epoc + duration = last date which is allowed)
And from these three it (hopefully) calculates the needed keysize for you. Beautiful!
The default has a keySize of 72 bits and gives nanoSecond precision from 1 January 1900 for 1000 years!
And this, (hopefully) is achieved simply with "MaDateAndTimeIndex new".
Chris, if you like this work, feel free to modify it and add it to Magma.
I like it very much. I will plan to add it.
Thanks! Chris
magma@lists.squeakfoundation.org
-
Brent Pinkney -
Chris Muller