[GemStone-Smalltalk] Bug?

[Martin McClure]

Hi David,

I'm sorry to hear you're having problems in this area.

After some research, I have come to the conclusion that this kind of 
mapping has never worked in GBS. I'll file a feature request, since it's 
something that *could* work.

A possible workaround would be to use GbsNameConnectors with a 
postConnectAction of #none, instead of GbsClassConnectors. I haven't 
extensively tested this, but it seems to basically work. I'd appreciate 
it if you could try that and let us know how well that works.

Thanks,
-Martin

On 3/20/21 2:04 PM, David Shaffer via GemStone-Smalltalk wrote:
> Here are some things I’ve tried:
>
> 1) Using the “base” VW class name but also setting the environment:
>
> (#{GbsClassConnector} value
> stName: ’ConflictingName'
> gsName: #ConflictingName
> dictionaryName: #GcbNSA) environment: GcbNSA
>
> But then adding the second connector with the same stName removes the 
> first (since GbsNameConnector>>= relies on #clientObjString which only 
> references stName).
>
> 2) Using both the full class name and specifying the environment:
>
> (#{GbsClassConnector} value
> stName: ’GcbNSA.ConflictingName'
> gsName: #ConflictingName
> dictionaryName: #GcbNSA) environment: GcbNSA
>
> This /kind-of/ works.  That is, both connectors stay around as long as 
> I disable connector verification but…when I store instances of the two 
> VW classes in GS, commit, log out then back in, they appear to be 
> instances of the same type.  I think this is a bug in 
> GbsSession>>fetchBehaviorDelegatesForClassConnectors: which seems to 
> ignore the #dictionaryName attribute of the connectors.
>
> I’m dead in the water.  Hacking 
> GbsSession>>fetchBehaviorDelegatesForClassConnectors: is next but I 
> feel like that’s a bad path to go down since there is likely other 
> broken code related to this problem.
>
> -D
>
>> On Mar 20, 2021, at 3:13 PM, David Shaffer 
>> <shaffer at SHAFFER-CONSULTING.COM 
>> <mailto:shaffer at SHAFFER-CONSULTING.COM>> wrote:
>>
>> Hey folks,
>>
>> I’m a bit stuck on this one…I’m using VW9, GS3.5.4, Gbs8.5, in case 
>> it matters.  For testing purposes I have two Dictionaries in my 
>> symbol list: #GcbNSA and #GcbNSB each with a class called 
>> ConflictingName.  On the VW side I have the same setup but with 
>> Namespaces.  I create two class connectors:
>>
>> #{GbsClassConnector} value
>> stName: ’GcbNSA.ConflictingName'
>> gsName: #ConflictingName
>> dictionaryName: #GcbNSA
>>
>> #{GbsClassConnector} value
>> stName: ’GcbNSB.ConflictingName'
>> gsName: #ConflictingName
>> dictionaryName: #GcbNSB
>>
>> But GemStone discards one of them with this error:
>>
>> GbsClassConnector stName: #'GcbNSA.ConflictingName' gsName: 
>> #ConflictingName
>>          - GbsClassConnector stName: #'GcbNSA.ConflictingName' 
>> gsName: #ConflictingName
>>          is overriding an existing connection.
>> GbsClassConnector stName: 'ConflictingName' gsName: #ConflictingName 
>> - GbsClassConnector
>>          stName: 'ConflictingName' gsName: #ConflictingName is 
>> overriding an existing
>>          connection.
>>
>> I don’t understand this at all.  While the “gsName” of the two 
>> connectors is the same, the dictionaryName is different so they 
>> shouldn’t conflict.  Has anyone encountered this?  Or have any 
>> suggestions?
>>
>> Basically this makes it impossible to map VW Namespaces to GS 
>> Dictionaries…which I was hoping to do as I make extensive use of 
>> “conflicting" class names in VW.  I’m left with creating GS class 
>> names by mangling all of the VW class names to include namespace 
>> info.  Not a path I hopped to go down...
>>
>> -D
>>
>
>
> _______________________________________________
> GemStone-Smalltalk mailing list
> GemStone-Smalltalk at lists.gemtalksystems.com
> https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gemtalksystems.com/mailman/private/gemstone-smalltalk/attachments/20210322/e890703c/attachment.htm>