> On 04 Dec 2015, at 5:22 , Sven Van Caekenberghe <s...@stfx.eu> wrote: > > According to http://bsonspec.org/spec.html there are indeed 2 different types > > "\x09" e_name int64 UTC datetime > > "\x11" e_name int64 Timestamp > > I would guess that you need 2 different (sub)classes in Pharo if you want to > honour this spec. It has little to do with the almost empty TimeStamp > subclass of DateAndTime having been removed. This is an API design issue > (decide on the Pharo to BSON type mapping).
Strictly speaking, Timestamp should've never been mapped;
"Timestamp - Special internal type used by MongoDB replication and sharding.
First 4 bytes are an increment, second 4 are a timestamp"
doesn't exactly agree with the smalltalk implementation:
nextTimestampPut: aTimestamp
self nextDateAndTimePut: aTimestamp
It's a problem when an existing application stored Timestamp instances with the
broken type, for the reason I explained.
I'd be fine with having a legacy-compatibility package containing Timestamp
class + bson extensions as before (even though it was broken) strictly for use
when migrating legacy applications.
That's what we have Monticello groups for, right? ;)
Cheers,
Henry
signature.asc
Description: Message signed with OpenPGP using GPGMail
