I will check. Thank you. The problem is definitely something related to 'reachability'. eg I can save the top level objects but the second level objects (eg instance varaibles of the top level) I can not get to save.
S. On Nov 1, 2011, at 2:59 PM, Lukas Renggli wrote: > Not sure if this is related, but the collection hierarchy got refactored in > Pharo at some point to include HashedCollection (AFAIR) as superclass. Maybe > this broke something with the persistence of Sets and Dictionaries? > > Lukas > > On Tuesday, 1 November 2011, mail list <[email protected]> wrote: > > I am trying to deploy a Pharo 1.3 image using Goods and running into some > > basic issues where my objects are not persisted by reachability. > > eg I put dictionary x at root under a key 'test' > > eg db root at: 'test' put x. > > db commit. > > Then at x i updated instance variable and add something to its dictionary > > and committ > > eg x intancevariable y at: 'key' put 'zzzz' > > db commit > > > > looking at the root x does not get updated with y. > > > > I have the majority of the test cases pasing except for testIdentitySet and > > testFlushAllRemovesAllUnreferenced. > > > > In testIdentitySet the following failure > > | set x y y2 | > > set := KKIdentitySet database: dbOne. > > x := 1@1. > > y := 2@2. > > set add: x. > > set add: y. > > self assert: (set includes: x). > > self assert: (set includes: y). > > self deny: (set includes: 1@1). -->fails > > > > set = (2@2,1@1) > > so it seems to think that x and 1@1 are the same. Which to me seems > > correct but I may be misunderstanding the testcase. > > > > Any thoughts or pointers to update my mistakes in using Goods db would be > > helpful. > > > > S. > > On Oct 31, 2011, at 5:49 PM, Marcus Denker wrote: > > > >> 13320 > >> ----- > >> > >> Issue 4945: Weird Settings filtering > >> http://code.google.com/p/pharo/issues/detail?id=4945 > >> > >> -- > >> Marcus Denker -- http://marcusdenker.de > >> > >> > > > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch
