[GemStone-Smalltalk] Namespaces in VW
Richard Sargent via GemStone-Smalltalk
gemstone-smalltalk at lists.gemtalksystems.com
Thu Oct 25 09:52:51 PDT 2018
Gemstone/S mailing list wrote
> Hi Richard,
>
> In fact I have done all sorts of things, like setting
> generateServerClasses: true
> and defining connectors for all classes with postConnectAction: #updateGS.
> I think my database classes are inconsistent, in particular I have the
> same classes in UserGlobals and UserClasses, and I don’t know which is
> which.
>
> I also had a clash in MessageSend, and ReadWriteStream, and I had to
> rework my data model not to use those classes.
>
> Is there a way to reset all user classes or even all the database ?
The easiest way would be to restore a copy of the "production" database from
which your development one was created and then push the code again.
The alternative is a lot more work, requiring you to track down all
instances of the classes and disconnect them from the object graph so that
they can be garbage collected, then delete the classes themselves.
> I have more or less succeeded in storing my object in the database now,
> and wanted to retrieve it.
>
> From a clean database, what would be the safest to do, define connectors
> or generating classes by program ?
In general, I think the best approach is to push your code to the server via
script along with using pre-established connectors to ensure the objects can
be mapped when needed.
You can study BrowserNavigator in the GbsMenusAndIcons package to see how it
pushes pundles or individual classes to the server.
> Best regards
>
>
> Annick
>
>> Le 24 oct. 2018 à 18:39, Richard Sargent via GemStone-Smalltalk <
> gemstone-smalltalk at .gemtalksystems
> > a écrit :
>>
>> Gemstone/S mailing list wrote
>>> Hi,
>>> I have tried the new VW client, but I don’t know how to map classes
>>> between client and server.
>>>
>>> Should I map :
>>>
>>> Compet.Competition -> Competition
>>> or
>>>
>>> Competition -> Competition ?
>>>
>>> If I do the second, updateGS does not work.
>>> If I do the first, updateST does not work.
>>
>> Hi Annick,
>>
>> The first case should work, but there are conditions under which it will
>> fail. However, before we can determine what's going wrong, we need a
>> better
>> understanding of what you are doing.
>>
>> 1. Are you establishing the connector through the dialogue and prior to
>> login, post login, manually, or what?
>> 2. When you say it doesn't work, what actually happens? If you get an
>> exception, a detailed stack report will help enormously.
>>
>> One of the greatest difficulties with name/class connectors is handling
>> new
>> versions of the class. The connector creates a mapping between the
>> objects
>> so identified at the time of login. A new class version has a different
>> object identifier and is not nor will it be mapped to the client class.
>>
>> Absent a new class version, updating the client class' methods from the
>> server class should work.
>>
>>
>>> Best regards
>>>
>>> Annick
>>> _______________________________________________
>>> GemStone-Smalltalk mailing list
>>
>>> GemStone-Smalltalk at .gemtalksystems
>>
>>> http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
>>> <http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk>
>>
>>
>>
>>
>>
>> --
>> Sent from: http://forum.world.st/Gemstone-S-f1461796.html
>> <http://forum.world.st/Gemstone-S-f1461796.html>
>> _______________________________________________
>> GemStone-Smalltalk mailing list
>>
> GemStone-Smalltalk at .gemtalksystems
> <mailto:
> GemStone-Smalltalk at .gemtalksystems
> >
>> http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
>> <http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk>
>
> _______________________________________________
> GemStone-Smalltalk mailing list
> GemStone-Smalltalk at .gemtalksystems
> http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
--
Sent from: http://forum.world.st/Gemstone-S-f1461796.html
More information about the GemStone-Smalltalk
mailing list