On Fri, Mar 28, 2014 at 4:18 PM, Michael Roland <mroland98343@gmail.com>wrote:
On Thursday, February 13, 2014 10:26:55 AM UTC-5, Tudor Girba wrote:
Hi,
I just retried DBXTalk, and it now magically works!
Does anyone know why? :)
I did this: Gofer new smalltalkhubUser: 'DBXTalk' project: 'DBXTalkDriver'; package: 'ConfigurationOfOpenDBXDriver'; load. #ConfigurationOfOpenDBXDriver asClass loadBleedingEdge.
Anyway, the only glitch I found is that the OpenDBX current wrongly returns "NBPharoOpenDBX class" instead of the instance.
I could not figure out where the initialization bug comes from, but I worked around it with: NBPharoOpenDBX installAsCurrent.
I tested the functionality with an Oracle backend, and it just worked.
Thanks!
Doru
-- www.tudorgirba.com
"Every thing has its own flow"
I tried DBXTalk today on Pharo 3 and got the NBPharoOpenDBX class error too. This is my understanding of what causes the error.
The value returned by OpenDBX class>>#current is initialized in ConfigurationOfOpenDBXDriver>>#setNBOpenDBX.
#setNBOpenDBX has one line: (Smalltalk at: #OpenDBX) current: (Smalltalk at: #NBPharoOpenDBX).
This sets OpenDBX Current to an NBPharoOpenDBX class instead of an NBPharoOpenDBX instance.
Changing the statement to: (Smalltalk at: #NBPharoOpenDBX) installAsCurrent
indirectly sets OpenDBX Current to an instance of NBPharoOpenDBX so that OpenDBX class>>#current will correctly return an instance of NBPharoOpenDBX.
Using OpenDBX class>>#installAsCurrent is needed because the OpenDBX class has two class variables: CurrentLibraryFactory and Current. CurrentLibraryFactory stores a class and Current stores an instance of that class. The only way to set CurrentLibraryFactory is with the OpenDBX class>>#installAsCurrent method. Using OpenDBX class>>#current: to set the instance directly can leave the CurrentLibraryFactory and Current variables out of sync.
Thanks! Michael was this committed to the repo? -- Mariano http://marianopeck.wordpress.com