Does it make sense to have Name: ConfigurationOfVoyageMongo-EstebanLorenzano.38 Author: EstebanLorenzano Time: 9 May 2015, 8:40:27.23963 am UUID: 9ba71817-b3f9-4f66-8579-e09e5deb5935 Ancestors: ConfigurationOfVoyageMongo-EstebanLorenzano.37 fixed a problem with the versionner tool in the Catalog for Pharo 40? Stef
Yes I think⦠I still do not update voyage to Pharo5 (there are not TimeStamps anymore). Esteban
On 04 Dec 2015, at 15:43, stepharo <stepharo@free.fr> wrote:
Does it make sense to have
Name: ConfigurationOfVoyageMongo-EstebanLorenzano.38 Author: EstebanLorenzano Time: 9 May 2015, 8:40:27.23963 am UUID: 9ba71817-b3f9-4f66-8579-e09e5deb5935 Ancestors: ConfigurationOfVoyageMongo-EstebanLorenzano.37
fixed a problem with the versionner tool
in the Catalog for Pharo 40?
Stef
so can you push it? Le 4/12/15 15:49, Esteban Lorenzano a écrit :
Yes I think⦠I still do not update voyage to Pharo5 (there are not TimeStamps anymore).
Esteban
On 04 Dec 2015, at 15:43, stepharo <stepharo@free.fr> wrote:
Does it make sense to have
Name: ConfigurationOfVoyageMongo-EstebanLorenzano.38 Author: EstebanLorenzano Time: 9 May 2015, 8:40:27.23963 am UUID: 9ba71817-b3f9-4f66-8579-e09e5deb5935 Ancestors: ConfigurationOfVoyageMongo-EstebanLorenzano.37
fixed a problem with the versionner tool
in the Catalog for Pharo 40?
Stef
On 04 Dec 2015, at 3:49 , Esteban Lorenzano <estebanlm@gmail.com> wrote:
Yes I think⦠I still do not update voyage to Pharo5 (there are not TimeStamps anymore).
Esteban
On 04 Dec 2015, at 15:43, stepharo <stepharo@free.fr> wrote:
Does it make sense to have
Name: ConfigurationOfVoyageMongo-EstebanLorenzano.38 Author: EstebanLorenzano Time: 9 May 2015, 8:40:27.23963 am UUID: 9ba71817-b3f9-4f66-8579-e09e5deb5935 Ancestors: ConfigurationOfVoyageMongo-EstebanLorenzano.37
fixed a problem with the versionner tool
in the Catalog for Pharo 40?
Stef
I found this to be kind of a big deal when trying to remove deprecations in 4.0, as TimeStamps and DateAndTime are mapped to different BSON classes... If you change Documents to use DateAndTime now instead of Timestamp now, and write them to a legacy database, they will save just fine, but Mongo will give errors if you try to sort documents by that field due to incompatible types. :/ Cheers, Henry
I was thinking what to do⦠maybe couple voyage with ZTimestamp could be a good idea?
On 04 Dec 2015, at 16:40, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On 04 Dec 2015, at 3:49 , Esteban Lorenzano <estebanlm@gmail.com> wrote:
Yes I think⦠I still do not update voyage to Pharo5 (there are not TimeStamps anymore).
Esteban
On 04 Dec 2015, at 15:43, stepharo <stepharo@free.fr> wrote:
Does it make sense to have
Name: ConfigurationOfVoyageMongo-EstebanLorenzano.38 Author: EstebanLorenzano Time: 9 May 2015, 8:40:27.23963 am UUID: 9ba71817-b3f9-4f66-8579-e09e5deb5935 Ancestors: ConfigurationOfVoyageMongo-EstebanLorenzano.37
fixed a problem with the versionner tool
in the Catalog for Pharo 40?
Stef
I found this to be kind of a big deal when trying to remove deprecations in 4.0, as TimeStamps and DateAndTime are mapped to different BSON classes... If you change Documents to use DateAndTime now instead of Timestamp now, and write them to a legacy database, they will save just fine, but Mongo will give errors if you try to sort documents by that field due to incompatible types. :/
Cheers, Henry
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).
On 04 Dec 2015, at 16:40, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On 04 Dec 2015, at 3:49 , Esteban Lorenzano <estebanlm@gmail.com> wrote:
Yes I think⦠I still do not update voyage to Pharo5 (there are not TimeStamps anymore).
Esteban
On 04 Dec 2015, at 15:43, stepharo <stepharo@free.fr> wrote:
Does it make sense to have
Name: ConfigurationOfVoyageMongo-EstebanLorenzano.38 Author: EstebanLorenzano Time: 9 May 2015, 8:40:27.23963 am UUID: 9ba71817-b3f9-4f66-8579-e09e5deb5935 Ancestors: ConfigurationOfVoyageMongo-EstebanLorenzano.37
fixed a problem with the versionner tool
in the Catalog for Pharo 40?
Stef
I found this to be kind of a big deal when trying to remove deprecations in 4.0, as TimeStamps and DateAndTime are mapped to different BSON classes... If you change Documents to use DateAndTime now instead of Timestamp now, and write them to a legacy database, they will save just fine, but Mongo will give errors if you try to sort documents by that field due to incompatible types. :/
Cheers, Henry
On 04 Dec 2015, at 17:22, Sven Van Caekenberghe <sven@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).
yes, often in databases datetime and timestamps are different beasts. Thatâs why I was thinking on importing a real timestamp, to honor mongo design⦠but I need to review what mongo (and others) consider actually as a timestamp :) Esteban
On 04 Dec 2015, at 16:40, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On 04 Dec 2015, at 3:49 , Esteban Lorenzano <estebanlm@gmail.com> wrote:
Yes I think⦠I still do not update voyage to Pharo5 (there are not TimeStamps anymore).
Esteban
On 04 Dec 2015, at 15:43, stepharo <stepharo@free.fr> wrote:
Does it make sense to have
Name: ConfigurationOfVoyageMongo-EstebanLorenzano.38 Author: EstebanLorenzano Time: 9 May 2015, 8:40:27.23963 am UUID: 9ba71817-b3f9-4f66-8579-e09e5deb5935 Ancestors: ConfigurationOfVoyageMongo-EstebanLorenzano.37
fixed a problem with the versionner tool
in the Catalog for Pharo 40?
Stef
I found this to be kind of a big deal when trying to remove deprecations in 4.0, as TimeStamps and DateAndTime are mapped to different BSON classes... If you change Documents to use DateAndTime now instead of Timestamp now, and write them to a legacy database, they will save just fine, but Mongo will give errors if you try to sort documents by that field due to incompatible types. :/
Cheers, Henry
On 04 Dec 2015, at 5:22 , Sven Van Caekenberghe <sven@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
Then why not introduce a MongoTimestamp and be done with it ?
On 04 Dec 2015, at 17:41, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On 04 Dec 2015, at 5:22 , Sven Van Caekenberghe <sven@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
Le 4/12/15 21:59, Sven Van Caekenberghe a écrit :
Then why not introduce a MongoTimestamp and be done with it ?
+1
On 04 Dec 2015, at 17:41, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On 04 Dec 2015, at 5:22 , Sven Van Caekenberghe <sven@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
Am 04.12.2015 um 16:40 schrieb Henrik Johansen <henrik.s.johansen@veloxit.no>:
On 04 Dec 2015, at 3:49 , Esteban Lorenzano <estebanlm@gmail.com> wrote:
Yes I think⦠I still do not update voyage to Pharo5 (there are not TimeStamps anymore).
Esteban
On 04 Dec 2015, at 15:43, stepharo <stepharo@free.fr> wrote:
Does it make sense to have
Name: ConfigurationOfVoyageMongo-EstebanLorenzano.38 Author: EstebanLorenzano Time: 9 May 2015, 8:40:27.23963 am UUID: 9ba71817-b3f9-4f66-8579-e09e5deb5935 Ancestors: ConfigurationOfVoyageMongo-EstebanLorenzano.37
fixed a problem with the versionner tool
in the Catalog for Pharo 40?
Stef
I found this to be kind of a big deal when trying to remove deprecations in 4.0, as TimeStamps and DateAndTime are mapped to different BSON classes... If you change Documents to use DateAndTime now instead of Timestamp now, and write them to a legacy database, they will save just fine, but Mongo will give errors if you try to sort documents by that field due to incompatible types. :/
Wouldn't it then be possible to include a timestamp class in Mongo? Norbert
On 04 Dec 2015, at 17:25, Norbert Hartl <norbert@hartl.name> wrote:
Am 04.12.2015 um 16:40 schrieb Henrik Johansen <henrik.s.johansen@veloxit.no>:
On 04 Dec 2015, at 3:49 , Esteban Lorenzano <estebanlm@gmail.com> wrote:
Yes I think⦠I still do not update voyage to Pharo5 (there are not TimeStamps anymore).
Esteban
On 04 Dec 2015, at 15:43, stepharo <stepharo@free.fr> wrote:
Does it make sense to have
Name: ConfigurationOfVoyageMongo-EstebanLorenzano.38 Author: EstebanLorenzano Time: 9 May 2015, 8:40:27.23963 am UUID: 9ba71817-b3f9-4f66-8579-e09e5deb5935 Ancestors: ConfigurationOfVoyageMongo-EstebanLorenzano.37
fixed a problem with the versionner tool
in the Catalog for Pharo 40?
Stef
I found this to be kind of a big deal when trying to remove deprecations in 4.0, as TimeStamps and DateAndTime are mapped to different BSON classes... If you change Documents to use DateAndTime now instead of Timestamp now, and write them to a legacy database, they will save just fine, but Mongo will give errors if you try to sort documents by that field due to incompatible types. :/
Wouldn't it then be possible to include a timestamp class in Mongo?
yes, but why duplicate? (*if* ZTimestamp is good, I would adopt it)
Norbert
participants (5)
-
Esteban Lorenzano -
Henrik Johansen -
Norbert Hartl -
stepharo -
Sven Van Caekenberghe