Smalltalk › Gemtalk › Gemstone/S

Bug?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Gemstone/S mailing list

Bug?

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
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

Gemstone/S mailing list

Re: Bug?

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 <[hidden email]> 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
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

Gemstone/S mailing list

Re: Bug?

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 <[hidden email]> 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
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

Gemstone/S mailing list

Re: Bug?

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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

GemstoneClassBuilder.st (11K) Download Attachment

BundleModel-allDefinedClasses.st (548 bytes) Download Attachment

Gemstone/S mailing list

Re: Bug?

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk