Smalltalk › Pharo › Pharo Smalltalk Users

Mongo configuration for Pharo40

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

13 messages Options

stepharo

Mongo configuration for Pharo40

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

EstebanLM

Re: Mongo configuration for Pharo40

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 <[hidden email]> 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
>

stepharo

Re: Mongo configuration for Pharo40

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 <[hidden email]> 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
>>
>
>

Henrik Sperre Johansen

Re: Mongo configuration for Pharo40

In reply to this post by EstebanLM

> On 04 Dec 2015, at 3:49 , Esteban Lorenzano <[hidden email]> 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 <[hidden email]> 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

signature.asc (859 bytes) Download Attachment

EstebanLM

Re: Mongo configuration for Pharo40

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 <[hidden email]> wrote:
>
>
>> On 04 Dec 2015, at 3:49 , Esteban Lorenzano <[hidden email]> 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 <[hidden email]> 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

Sven Van Caekenberghe-2

Re: Mongo configuration for Pharo40

In reply to this post by Henrik Sperre Johansen

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

NorbertHartl

Re: Mongo configuration for Pharo40

In reply to this post by Henrik Sperre Johansen

> Am 04.12.2015 um 16:40 schrieb Henrik Johansen <[hidden email]>:
>
>
>> On 04 Dec 2015, at 3:49 , Esteban Lorenzano <[hidden email]> 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 <[hidden email]> 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

EstebanLM

Re: Mongo configuration for Pharo40

In reply to this post by Sven Van Caekenberghe-2

> On 04 Dec 2015, at 17:22, Sven Van Caekenberghe <[hidden email]> 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 <[hidden email]> wrote:
>>
>>
>>> On 04 Dec 2015, at 3:49 , Esteban Lorenzano <[hidden email]> 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 <[hidden email]> 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
>
>

EstebanLM

Re: Mongo configuration for Pharo40

In reply to this post by NorbertHartl

On 04 Dec 2015, at 17:25, Norbert Hartl <[hidden email]> wrote:

Am 04.12.2015 um 16:40 schrieb Henrik Johansen <[hidden email]>:

On 04 Dec 2015, at 3:49 , Esteban Lorenzano <[hidden email]> 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 <[hidden email]> 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

Henrik Sperre Johansen

Re: Mongo configuration for Pharo40

In reply to this post by Sven Van Caekenberghe-2

On 04 Dec 2015, at 5:22 , Sven Van Caekenberghe <[hidden email]> 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 (859 bytes) Download Attachment

Henrik Sperre Johansen

Re: Mongo configuration for Pharo40

> On 04 Dec 2015, at 5:41 , Henrik Johansen <[hidden email]> wrote:
>
>
> That's what we have Monticello groups for, right? ;)
>

I meant to write *Metacello* groups, obviously...

Cheers,
Henry

signature.asc (859 bytes) Download Attachment

Sven Van Caekenberghe-2

Re: Mongo configuration for Pharo40

In reply to this post by Henrik Sperre Johansen

Then why not introduce a MongoTimestamp and be done with it ?

> On 04 Dec 2015, at 17:41, Henrik Johansen <[hidden email]> wrote:
>
>
>> On 04 Dec 2015, at 5:22 , Sven Van Caekenberghe <[hidden email]> 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

stepharo

Re: Mongo configuration for Pharo40

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 <[hidden email]> wrote:
>>
>>
>>> On 04 Dec 2015, at 5:22 , Sven Van Caekenberghe <[hidden email]> 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
>
>