I'm glad you were able to figure that out. Thanks for writing up
your solution.
Happy to be help, given the great value similar efforts by others
have been to me.
me of still-unexplained deletion.
That deletion is pretty frightening. Nobody else has reported that
problem, so I hope it is a one-time fluke or user-error on your part.
Any ideas how it could have happened?
Ideas? --->
First, (eliminating the obvious) nothing was missing from the MySQL
dumps used to populate the development machine databases. The errors
resulted from the upgrade process as it took place here. User error
is still on the table.
Second, evidence suggests that loads to development machines went well.
Third, initial error messages from roller were apparently not
database-centric.
My implementations of the tag cloud and so on were the cause of
those. No db changes required by those implementations. No code in
them which looks as though it could delete db fields or the contents
of tables.
That seems to leave (a) user error associated with the database
table upgrades, (b) code within roller associated with the upgrades
and (c) a combination of those two. Overwhelmingly general categories.
The initial fatal errors reported during this upgrade arose from
what appeared at the time to be omissions in the scripted upgrades
from version to version.
The first involved with the "spam" field in the roller_comment table.
Simply put, it wasn't there.
That "spam" field was and is in the baseline "createdb.sql" script
for MySQL. I apologize, but I have yet to determine when it was
created (during the migration from version to version).
Other error messages seemed at the time to be uninformative and
possibly spurious.
For example, at startup there were messages complaining about failed
attempts to upgrade the database to a more recent version. At the
time, I concluded that those resulted from an upgrade failure to
change the version number as they walked up the version tree.
Although I inferred there would be no consequences, I looked at the
database for gross changes. Finding none, I moved on.
I am reviewing that decision.
As other tasks take me back into the source late today or early
tomorrow, I'll look at the associated code. If I find issues, I'll
report them on the development list. Or here if you prefer.
Interactions between an aggressive user, the scripts applied from
dbscripts and the code seem to me at this moment to be the most
likely candidate explanation.
Seem reasonable to you?
In retrospect, I should have devoted more time to reading and
enjoying the source code which emitted the two errors which
confounded me.
Had I done so as my first recourse, I would have
understood each
error and its associated stack trace as a meaningful error message.
No excuse.
It does occur to me, and perhaps I am being unreasonable
here, that
those who have not been programming in Java for a few years might
perhaps benefit from error messages which are somewhat more
expressive in a literary sense.
Better error messages would definitely be helpful everywhere in
Roller. Users should never have to resort to reading the source code.
But database corruption is non a common event with Roller (or at least
with post 1.x Roller), they're hard to recover from and hard to
explain via error messages.
You are I believe on point regarding the rarity of database errors
and the difficulty of creating error-message explanations of them.
Without disagreeing with you, it does seem to me that one might
reasonably anticipate the need for meaningful messages regarding
missing fields and/or the absence of whole tables. When that happens
it tends to be a serious problem, as you noted. Hence my suggestion.
Messages referring to "this._spam" without allusion to a specific
table or the database in general may avoidably prolix.
In-code documentation is somewhat related. Roller's documentation
seems to me to be quite good. Newcomers to the code would benefit
from slight improvement at the method level.
Just a thought.
One reasonable rejoinder would be that if I feel strongly
enough to
voice that sentiment in public, I should offer code (which would be
accepted or discarded as appropriate). Not talk. Point taken (falls
silent ... turns to keyboard).
Specific suggestions for improving error messages would also be
helpful.
- Dave
