Strange Dictionary behavior

Avi,

    I've saw a Proxy of #x evaluating to false against a #x. In fact it's
the case of a dictionary whit this #x as key of the 1 value.

    ...  element key = #x

    element key is the proxy to #x stored and it evaluates to false.

    Could be this due to the Object>>= method?

    How do you suggest the = proxy-object thing coul be resolved?

    Where may I put the 'resolve' method in the client code, (the resolve
suggested by Bill Dargel) to acomplish this?

    regards,

Seb



"Avi Bryant" <[hidden email]> escribió en el mensaje
news:[hidden email]...
> "Sebastián Sastre" <[hidden email]> wrote in message
news:<c5p2lf$433pg$[hidden email]>...
>
> > If I get your point the code should be like this
> > KKVariableFieldContainer>>refreshVariablePartOfObject: anObject
fromStream:
> > aStream
> >
> > 1 to: anObject basicSize do:
> >
> > [:i | anObject basicAt: i put: (fieldType fieldFromStream: aStream)]
> >
> > I've stored a dictionary like that but when is restored it has the
problem

"Sebastián Sastre" <[hidden email]> wrote in message news:<c60rtb$6f4cm$[hidden email]>...
Yes, no doubt.

>     How do you suggest the = proxy-object thing coul be resolved?

Object>>resolve
  ^ self

Object>>= other
 ^ self == other resolve

KKObjectProxy>>resolve
  ^ self xxxObject

Avi

"Sebastián Sastre" <[hidden email]> wrote in message news:<c60rig$6k6dm$[hidden email]>...
 
>     If I put some object into it, and commit the changes, when I call back
> it from the DB the dic is unable to find the key (inspecting it you can see
> it have it but is not able to recover it I'm looking why).

As your later message indicates, this is probably to do with Object>>=.

>     so... this does mean #isVariable is not a problem anymore?

Yes.

Avi,

    I've created the resolve method it worked with a minor issue en
Dictionary>>findKeyOrNil:
because
anObject = element key was giving false

element key = anObject was giving true

This was because the implementation of = is made on anObject or
aKKObjectProxy, so in the case of a Symbol (with the = optimized) the result
was false.

Now the dictionary is working.
Additionally I've created Object>>copyFrom: that in dolphin was missing and
was a little difficult to debug bacause it was raising no exception.

So..  now the port is passing 3 of 4 test. The only still failing is the
TransactionsTest.

    Making it manually, step by step on a workspace (a lot easier to debug)
I see that an association with a string as key and a collection as value

('TestNode1' -> an OrderedCollection(1 2 3 4 5 6 7 8 9 10))

cannot commit. It fails with a UndefinedObject DNU  #do:

    the previous message is
KKVariableFieldContainer>>writeVariableArrayFrom:onStream:

and I think it shouldn't be variable (correct me if I'm wrong please)perhaps
due to the


KKVariableFieldContainer>>writeObject: anObject onStream: aStream

anObject class isVariable           (is evaluating to false)

ifTrue: [self writeVariablePartOfObject: anObject onStream: aStream]

ifFalse: [self writeVariableArrayFrom: anObject onStream: aStream]


regards,

Seb

What's the value of the 'name' ivar of that KKVariableFieldContainer?

Avi

"Avi Bryant" <[hidden email]> escribió en el mensaje
news:[hidden email]...
> > So..  now the port is passing 3 of 4 test. The only still failing is the
> > TransactionsTest.
> >
> >     Making it manually, step by step on a workspace (a lot easier to
debug)
Sorry for the delay Avi.
Actually now the transaction commits OK, but new issues has arrived :/

I found that using a WeakIdentityDictionary for the objectRecords in
KKRecordCache, brings unexpected results. I mean, sometime in dolphin the
objectRecords are garbageCollected before the KKRecordCache send them to the
connection to be writed. It only happens sometimes but very ofen, resulting
in lots of loose of changes.

In the other hand, making the transaction test from a workspace, when the
dbTwo is refreshed, it gets a string of little squares instead of the
ordered collection with numbers stored in the value 'TestNode1' of the root
dictionary. Trying to be sure about how is the client serializing the
collection, I disconnected the db, shutdown goods, started up again and
connecting again to inspect the root object. In fact the collection returns
OK. It shows there may be a problem on the refresh.

How can I track it?

I made a lot of little tests in some methods in streams and bytearrays to
see if the results in dolphin and squeak are the same for those methods that
came from squeak, like Float>>asIEEE32BitWord. And all them are passing OK.

Any clue?

thanks,

--
Sebastián Sastre
[hidden email]
www.seaswork.com.ar

> Sorry for the delay Avi.
> Actually now the transaction commits OK, but new issues has arrived :/
>
> I found that using a WeakIdentityDictionary for the objectRecords in
> KKRecordCache, brings unexpected results. I mean, sometime in dolphin the
> objectRecords are garbageCollected before the KKRecordCache send them to
the
> connection to be writed. It only happens sometimes but very ofen,
resulting
> in lots of loose of changes.
Now I've found that those loose of changes can be avoided making a change
and inmidiately commiting. But I think the use of the client you've made for
squeak is not expecting that, I mean you can use it modifying all what you
want and then at some point make a commit (in an ok from a dialog for
example).
If objectRecords have a normal dictionary this could be a problem?

> In the other hand, making the transaction test from a workspace, when the
> dbTwo is refreshed, it gets a string of little squares instead of the
> ordered collection with numbers stored in the value 'TestNode1' of the
root
> dictionary. Trying to be sure about how is the client serializing the
> collection, I disconnected the db, shutdown goods, started up again and
> connecting again to inspect the root object. In fact the collection
returns
> OK. It shows there may be a problem on the refresh.
>
> How can I track it?
>
> I made a lot of little tests in some methods in streams and bytearrays to
> see if the results in dolphin and squeak are the same for those methods
that
> came from squeak, like Float>>asIEEE32BitWord. And all them are passing
OK.