13320 ----- Issue 4945: Weird Settings filtering http://code.google.com/p/pharo/issues/detail?id=4945 -- Marcus Denker -- http://marcusdenker.de
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
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 <mail.list@ficonab.com> 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
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 <mail.list@ficonab.com> 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
let us know because core collection should be really robust. Stef On Nov 1, 2011, at 9:52 AM, mail list wrote:
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 <mail.list@ficonab.com> 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
Let me come up with a proper failing testcase and I will update the list. I was hoping for some general insight as I assumed it was just my misuse of the packages. S. On Nov 1, 2011, at 5:34 PM, Stéphane Ducasse wrote:
let us know because core collection should be really robust.
Stef
On Nov 1, 2011, at 9:52 AM, mail list wrote:
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 <mail.list@ficonab.com> 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
Hi On 01 Nov 2011, at 1:41 PM, mail list wrote:
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.
KKIdentitySet should not think x and 1@1 are the same as they are 2 different instances. I would think that the implementation of Set has changed (@see scanFor: method, specifically the SetElement wrapper around nil). My guess would be that Set storage has changed slightly. Maybe try changing KKIdentitySet to be: KKIdentitySet>>scanFor: anObject "Scan the key array for the first slot containing either a nil (indicating an empty slot) or an element that matches anObject. Answer the index of that slot or raise an error if no slot is found. This method will be overridden in various subclasses that have different interpretations for matching elements." | index start | index := start := anObject hash \\ array size + 1. [ | element | ((element := array at: index) == nil or: [ element enclosedSetElement == anObject ]) ifTrue: [ ^index ]. (index := index \\ array size + 1) = start ] whileFalse. self errorNoFreeSpace Cheers Carlo
So i now have GOODs working semi reliably and as expected on Pharo 1.3 (squeaksource GOODS). I still don't know the root cause but I will work on it. I will just document my problem and how i fixed it in case anyone else runs into the same issue. I will also look at submitting the new test cases to the GOODs on squeaksource The root of the object database in goods is a Dictionary - pointing to various objects including a dictionary of users for seaside. When I would login the user into the seaside session, I would look up object previously from the dictionary of users. I then assume that any changes to the users would be persisted by the db commit command. eg establish xDict:= lookup dictionary of users from Goods session establish connection to database session login user using xDict to check for password etc. change user or subobjects ---> changes to the subojects were not saved here! session db commit --> write it all to the database. session logout -- disconnect db. the problem was that xDict was not linked to Goods anymore or had grown stale. So i could make a change to user and it would save but the sub objects would not be updated. The fix is during the session login user I need to traverse the entire goods db to retrieve the user. Then all commits etc work. eg: establish xDict:= lookup dictionary of users from Goods session establish connection to database session login user ---from xDict tUser:= traverse Goods until you find user save tUser (not the one found from xDict) . change user or subobjects session db commit --> write it all to the database. session logout -- disconnect db. S. On Nov 1, 2011, at 7:41 PM, mail list wrote:
Let me come up with a proper failing testcase and I will update the list. I was hoping for some general insight as I assumed it was just my misuse of the packages.
S. On Nov 1, 2011, at 5:34 PM, Stéphane Ducasse wrote:
let us know because core collection should be really robust.
Stef
On Nov 1, 2011, at 9:52 AM, mail list wrote:
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 <mail.list@ficonab.com> 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
On Tue, Nov 1, 2011 at 4:18 AM, mail list <mail.list@ficonab.com> 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
It looks like a bug in KKIdentitySet. Because if you use a regular IdentitySet instead, of course the test works. Maybe GOODS is outdated....
set = (2@2,1@1) so it seems to think that x and 1@1 are the same.
They are equal but not the same. How can we load GOODS? in which pharo image? and give us a test we can reproduce.
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
-- Mariano http://marianopeck.wordpress.com
participants (6)
-
Carlo -
Lukas Renggli -
mail list -
Marcus Denker -
Mariano Martinez Peck -
Stéphane Ducasse