[GemStone-Smalltalk] Bug?

[Richard Sargent]

David,

I have published changes so that name connector and its subclasses will
properly recognize the specification of a symbol dictionary. This will
allow classes such as the following to each be put into a separate symbol
dictionaries and yet have the same class name. You will still have the
issue of referencing them individually from code at compile time. You can
always handle it with source expressions like ( GbtNamespaceA  at:
#GbtNamespaceTestClass) or ensuring that the right symbol dictionary
precedes the other when compiling the referencing code.

GbtNamespaceA.GbtNamespaceTestClass
GbtNamespaceB.GbtNamespaceTestClass

If you have a connector with a dictionary specified, it will be an error if
the named object cannot be found (unless your post-connection action is to
update GS, in which case, it will be created). GbtNameConnector will not do
a good job of creating classes because the class is created after the
connection is established and is created independently of any connector
knowledge at that time. Use GbtClassConnector for connecting classes.

These changes will be in the next release of GBS for VisualWorks. We do not
have a planned release date yet.


On Tue, Mar 23, 2021 at 8:30 AM David Shaffer via GemStone-Smalltalk <
gemstone-smalltalk at lists.gemtalksystems.com> wrote:

> Thanks Martin,
>
> I decided to go the “class name mangling” direction.  It was easier than I
> thought.  So now I map VW class names X.Y.Class to X_Y_Class.  Life is good
> again :). I’ll give GbsNameConnector a try when I have some down time since
> I would prefer using the same names on both systems.  While VW namespaces
> and GS symbol dictionaries are different, they seem similar enough to make
> it work.  In GOODS I created a “class name mapper” whose job it was to map
> St class names to and from GOODS class name.  This mapper could be plugged
> into a session so any automatic translation would use the mappings.  I
> could imagine this would be useful in GS in a couple of situations:
>
>
>    - St->GS class generation in the browser could use it
>    - When “generate class connectors” setting is true, connector
>    generation would consult the mapping
>    - When “generate server classes” setting is true, class generation
>    would consult the mapping
>
>
> The mapping would specify how VW namespaces map to GS symbol dictionaries
> and how VW class names transform into GS class names.  Some built-in
> implementations could be:
>
>    - Namespace ignored (all classes in same SD), St class name = GS class
>    name
>    - Namespace <-> SD, St class name = GS class name
>    - Namespace ignored (all classes in same SD), GS Class name  = mangled
>    St class name to prefix with NS name
>
>
> This would make it easier for people to avoid the manual “tooling" when
> they’re getting started in GS but already have complex persistent models.
> I’ve attached my class creation tool…it isn’t in great shape because of the
> fumbling around but it might be useful for reference for people new to GS.
>
> Best,
>
> David
>
>
> On Mar 22, 2021, at 10:20 PM, Martin McClure <
> martin.mcclure at gemtalksystems.com> wrote:
>
> 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>
> 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 listGemStone-Smalltalk at lists.gemtalksystems.comhttps://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
>
>
>
> _______________________________________________
> 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/20210329/f30a5100/attachment.htm>