Please look at the attached partial screen dump.
The 'Variables' match somewhat with the execution step, although @subt should be a SubTransaction, not a SubBundle as shown.
The @attributes under @subb (which is a SubBundle) are correct.
The @attributes under @subt (not shown here) show that it is not a SubTransaction, but a SubBundle - exactly the same as @subb
In the 'Watches' window, the attributes of @subb show that it is really a SubTransaction and not a SubBundle (which it should be). In fact, the attributes in the Watch window show that @subb is actually the @subt which should be shown in the 'Variables' window.
:-) I don't expect you to follow along too closely. Just accept the fact that there seems to be a sync problem between the variables and watches shown as one steps through the execution using the debugger step commands. Occasionally, things are properly synced.
Is it possible to get it to sync more often?
(I'm sorry I don't have a smaller test application to illustrate the problem).
I'm stepping through again - variables seem to be in sync. Perhaps what I was seeing before was one thread stepping on another in the debugger view.
I have made no code changes in my application.
I restarted the webrick server and re-ran my application up to the same breakpoint.
@subb is now a SubBundle and @subt is now a SubTransaction.
Whoops, @subb is now a SubTransaction in the Watch window - not so good.
And in the Variables window, @subt and @subb are pointing to the same SubBundle.
The only difference is a few steps of code:
@subb.account = account
@subb.hashapprox = hashapprox
@subb.hashexact = hashexact (not yet executed. Debugger highlight on this line)
Just setting attributes
OK, I have info.
As I step through the execution, when I am on the
@subb.hashapprox = hashapprox
statment, everything is OK.
When I move to the next statement (but not execute it)
@subb.hashexact = hashexact
Then the variables shown in the Variables window and the Watch window more or less exchange places.
This is before the execution of the hashexact statement.
However, THERE IS NO hashexact COLUMN in the sub_bundle database. This is probably why the problem occurs.
It is odd that weird things happen BEFORE the statement is executed.
Also odd that RubyMine did not pick up that error. Perhaps because the adjacent object, @subt DOES contain that column.
I will now change some code and do a migration or two.
Except for the fact that RubyMine did not pick up the coding error, I think my problem is solved.
Watch variables are still not synced with Variables.
The behavior seems to be -
A Watched variable is nil before it is newed
The Watched variable is proper after it is newed
After an attribute of a Watched variable is changed, the Watched variable is out of sync
After the next attribute of a Watched variable is changes, things come into sync
After the Watched variable is 'saved', it is out of sync
After the next assignment, things come into sync again.
Once I get the rhythm it isn't too bad. However, when bad things happen in my code, the Watch variables are usually out of sync
THE OUT OF SYNC IS NOT RELATED TO THE MISSING COLUMN IN THE DATABASE, so the problem is really NOT solved.
Bob, please try installing this version http://teamcity.jetbrains.com/repository/download/bt279/44841:id/ruby-debug-ide-0.4.17.alpha.gem of ruby-debug-ide gem and see if the problem with inconsistency is still there
The teamcity web site is asking me for a username and password. Is this a new login or do I use the same login credentials as for this discussion?
You can simply select Login as guest at bottom of the page
I think I have the ruby-debug-ide 0.4.17.alpha installed correctly:
[user1@hoho6 ~]$ gem list ruby-debug -a
*** LOCAL GEMS ***
ruby-debug-base19 (0.11.25.jb3, 0.11.24)
ruby-debug-ide (0.4.17.alpha, 0.4.16, 0.4.15)
However, the results are still strange. In the screen picture below, see the
'subt' in both the Variables and Watches windows. They are different.
Also, the Watch variable 'ex_save' should not have a value because it is not in scope yet.
The blue hightlight line in the code editor window shows that execution is paused outside of the loop where 'ex_save' is defined.
This is happening to me as well.
The Watch window has about a 50% chance of having the right object in it. I've noticed that it hasn't improved in RubyMine 4 EAP.