Re: [Pharo-users] [Pharo-dev] Changed semantics for mongo ObjectID
Hi Norbert, what about objects which have been written to mongo with the old version and will be read with the new version. Can they be read/found with the new version? Or is there a migration needed? Regards Sabine On Thu, May 8, 2014 at 11:30 PM, Norbert Hartl norb...@hartl.name wrote: I needed to change the way ObjectIds are read from and written to BSON. BSON is a format that encodes its byte contents little endian. In mongo database the format of ObjectIds is different. The way an ObjectId is encoded is big endian. You can see this if you compare the outputs for an object when read from mongo shell and from pharo. The ids won’t match. If you do „normal“ stuff with mongo it is unlikely you have noticed the effect. An OID is read the wrong way but also written the wrong way which makes it right again from the mongo database perspective. But it won’t work if you use a mixed query setting. Meaning reading an OID and requesting the database using javascript expression. This will fail. I’m writing this because I’m not sure the change can break existing software. The change is not included in the stable version, yet. If you want to test then load #bleedingEdge and report any problem that might occur. I will use the new behaviour and will take the freedom to make it stable if it works for some time. FYI, Norbert
Re: [Pharo-users] [Pharo-dev] Changed semantics for mongo ObjectID
Am 12.05.2014 um 10:46 schrieb Sabine Knöfel sabine.knoe...@gmail.com: Hi Norbert, what about objects which have been written to mongo with the old version and will be read with the new version. Can they be read/found with the new version? Or is there a migration needed? I’d say it should be safe just to upgrade the code. The exisiting ids won’t change because encoding and decoding are always fully reversible. Meaning regardless of the encoding scheme the ids are the same in the database after being read and written. The only thing changes is the value in the OID object in your image. There are two ways where this can fail. Either you monkey with id values inside your code. Or you use manual references to objects where the referenced id is not written as OID. Everything else should be the same with the old and the new code. In the meantime I even changed the generation of the id value to reflect the mongo spec. Now the values should be comparable to what other drivers (including mongo shell) are generating. This also means you can now ask your ObjectId about its timestamp. Which of course gives you non-sense with ids generated prior to the code update.. Norbert On Thu, May 8, 2014 at 11:30 PM, Norbert Hartl norb...@hartl.name wrote: I needed to change the way ObjectIds are read from and written to BSON. BSON is a format that encodes its byte contents little endian. In mongo database the format of ObjectIds is different. The way an ObjectId is encoded is big endian. You can see this if you compare the outputs for an object when read from mongo shell and from pharo. The ids won’t match. If you do „normal“ stuff with mongo it is unlikely you have noticed the effect. An OID is read the wrong way but also written the wrong way which makes it right again from the mongo database perspective. But it won’t work if you use a mixed query setting. Meaning reading an OID and requesting the database using javascript expression. This will fail. I’m writing this because I’m not sure the change can break existing software. The change is not included in the stable version, yet. If you want to test then load #bleedingEdge and report any problem that might occur. I will use the new behaviour and will take the freedom to make it stable if it works for some time. FYI, Norbert
Re: [Pharo-users] [Pharo-dev] Changed semantics for mongo ObjectID
Thanks, Norbert! On Mon, May 12, 2014 at 11:38 AM, Norbert Hartl norb...@hartl.name wrote: Am 12.05.2014 um 10:46 schrieb Sabine Knöfel sabine.knoe...@gmail.com: Hi Norbert, what about objects which have been written to mongo with the old version and will be read with the new version. Can they be read/found with the new version? Or is there a migration needed? I’d say it should be safe just to upgrade the code. The exisiting ids won’t change because encoding and decoding are always fully reversible. Meaning regardless of the encoding scheme the ids are the same in the database after being read and written. The only thing changes is the value in the OID object in your image. There are two ways where this can fail. Either you monkey with id values inside your code. Or you use manual references to objects where the referenced id is not written as OID. Everything else should be the same with the old and the new code. In the meantime I even changed the generation of the id value to reflect the mongo spec. Now the values should be comparable to what other drivers (including mongo shell) are generating. This also means you can now ask your ObjectId about its timestamp. Which of course gives you non-sense with ids generated prior to the code update.. Norbert On Thu, May 8, 2014 at 11:30 PM, Norbert Hartl norb...@hartl.name wrote: I needed to change the way ObjectIds are read from and written to BSON. BSON is a format that encodes its byte contents little endian. In mongo database the format of ObjectIds is different. The way an ObjectId is encoded is big endian. You can see this if you compare the outputs for an object when read from mongo shell and from pharo. The ids won’t match. If you do „normal“ stuff with mongo it is unlikely you have noticed the effect. An OID is read the wrong way but also written the wrong way which makes it right again from the mongo database perspective. But it won’t work if you use a mixed query setting. Meaning reading an OID and requesting the database using javascript expression. This will fail. I’m writing this because I’m not sure the change can break existing software. The change is not included in the stable version, yet. If you want to test then load #bleedingEdge and report any problem that might occur. I will use the new behaviour and will take the freedom to make it stable if it works for some time. FYI, Norbert
[Pharo-users] Problem learning about Magritte
Hello Sorry if this is the wrong place to ask this. I am trying to understand how Magritte works, initially by following the first example in Ch. 26.2 of the Seaside book. I have started with a fresh download of Pharo 3.0, and I have installed Magritte 3 and Seaside 3. I realise that the Seaside book example is based on Magritte 2, so I have made necessary changes to the example code (descriptions are on the instance side, insert magritteDescription pragmas, change #description to #magritteDescription). All works well up to the point where I try to generate the Seaside editor. This fails because the code: Address example1 asComponent produces a 'does not understand' message for #asComponent. I have not been able to work through all of Seaside to see where this method is defined, and I am at a bit of a loss. I know this is rather elementary, but could someone give me a pointer? Also, if Magritte 3 is now the norm, will the Seaside book examples be updated to reflect this? Thanks in advance for any help Peter Kenny
Re: [Pharo-users] Problem learning about Magritte
Hi Peter That sounds like you have independently installed Seaside and Magritte. You might miss the part connecting them together. Seaside can be used without Magritte, and Magritte without Seaside. That happens if you just install stable Seaside and stable Magritte from the configuration browser. Can you check if you have Magritte-Seaside loaded? That is in the Seaside group of Magritte. If not, you need the other option in the configuration browser, just loading the configuration of Magritte3. Then in a workspace, do-it (ConfigurationOfMagritte3 project version: #stable) load: 'Seaside'. A faster way to start can be to use one of the images from https://ci.inria.fr/pharo-contribution/ Pier, QCMagritte and Forum all come with both Magritte and Seaside preloaded. Stephan
Re: [Pharo-users] Problem learning about Magritte
Esteban wrote: I don't like this faster way of prebuilt images. Makes me think of seeds for forked branches. Unless something is wrong with the package system, I would encourage its use, even if it takes long. I strongly encourage the use of ci images. And of course you should add your own, once you've decided what packages you need. The main advantage is that it provides feedback to the core pharo development on changes. Stephan
Re: [Pharo-users] Problem learning about Magritte
2014-05-12 20:47 GMT-03:00 Stephan Eggermont step...@stack.nl: Esteban wrote: I don't like this faster way of prebuilt images. Makes me think of seeds for forked branches. Unless something is wrong with the package system, I would encourage its use, even if it takes long. I strongly encourage the use of ci images. And of course you should add your own, once you've decided what packages you need. The main advantage is that it provides feedback to the core pharo development on changes.
Re: [Pharo-users] Problem learning about Magritte
2014-05-12 20:47 GMT-03:00 Stephan Eggermont step...@stack.nl: Esteban wrote: I don't like this faster way of prebuilt images. Makes me think of seeds for forked branches. Unless something is wrong with the package system, I would encourage its use, even if it takes long. I strongly encourage the use of ci images. And of course you should add your own, once you've decided what packages you need. The main advantage is that it provides feedback to the core pharo development on changes. I'm totally in about CI images for testing purposes, but not for distribution. Maybe it's a matter of personal taste. Esteban A. Maringolo ps: sorry for the off topic
