Migrate errs to problems? about errbit HOT 10 CLOSED

Hi there,

The first step is to run 'rake db:migrate' to update your database. Sorry
that was not made clear, we need to figure out a way of notifying people to
do that after the upgrade.

The migration may take a long time (up to 15 minutes if you have a lot of
errors to move.)

Please let me know if you still have any problems after this.

On Sun, Oct 2, 2011 at 12:24 AM, Gerrit Riessen <
[email protected]>wrote:

Hi,

don't really know what is going on (so the subject might not be correct)
but I just upgraded from revision f18852d
(sept 21.) to the latest master 3851c29
(sept 30.) and prompt i have an extra admin user and all errors (resolved
and not resolved) aren't showing on the UI (they seem to remain in the
database).

From what i saw, there is now a new model - Problem - and the Err modle
seems to belong to that. I.e. Problems are now being shown instead of Errs
and Errs are attached to a Problem (to cluster Errs?). Anyway, is there a
migration strategy for existing data?

Also, i noticed the the _table partial for errs has changed and doesn't
show issue links (if an error has an issue). Is this know handled somewhere
else or aren't issues created anymore from errbit?

Sorry if this already covered somewhere else + Thanks for the new styling
:)

Reply to this email directly or view it on GitHub:
#97

from errbit.

ok did a db:migrate and now instead of 7 errors, i've got 101! it seems that all the resolved errors become unresolved...

also are attached issues shown in the listing of errors or are they now shown somewhere else?

otherwise the UI is much better - Thanks :)

from errbit.

Oh, that doesn't sound good! I'm really sorry about that. We didn't
experience that when we upgraded at our organisation.
I'm not aware of anything in the migration that would cause that to happen..
(
https://github.com/errbit/errbit/blob/master/db/migrate/20110905134638_link_errs_to_problems.rb
)

Ah, I see what you mean about attached issues in the listing of errors! That
must have been overridden by the recent UI changes. I will change that back
now, thanks for letting me know!

Glad you like the changes :)

On Sun, Oct 2, 2011 at 12:41 AM, Gerrit Riessen <
[email protected]>wrote:

ok did a db:migrate and now instead of 7 errors, i've got 101! it seems
that all the resolved errors become unresolved...

also are attached issues shown in the listing of errors or are they now
shown somewhere else?

otherwise the UI is much better - Thanks :)

Reply to this email directly or view it on GitHub:
#97 (comment)

from errbit.

oh, it's not an issue on the production server, i'm doing this locally first before deploying - so nothing is lost or changed. i'll have a look at what's going on, i'll import the old data and redo the migration ... rinse&repeat....

another thing i noticed is that the timestamps have changed, they're now "Sep 26 10:23P" (from the deploy listing). Now that is unfortunately only half correct "Sep 26 10:23am" should be the correct time! I.e. there is always a 'P' regardless whether pm or am... and it's not 24-hour clock (which would be perferable for us).

from errbit.

Ah, ok. Would be really grateful if you would be able to help us figure out
those problems.

We recently added support for different timezones per user (
https://github.com/errbit/errbit/pull/90/files), but I'm not sure why this
would have messed up your times.. We've had no problems with that on our
instance of Errbit. Just deployed Errbit and the deploy time showed as "Oct
02 1:04am". So I'm very confused as to why you are getting '10:23P'..

Hope we can sort out all of these issues very fast, thanks for getting in
contact!

On Sun, Oct 2, 2011 at 1:00 AM, Gerrit Riessen <
[email protected]>wrote:

oh, it's not an issue on the production server, i'm doing this locally
first before deploying - so nothing is lost or changed. i'll have a look at
what's going on, i'll import the old data and redo the migration ...
rinse&repeat....

another thing i noticed is that the timestamps have changed, they're now
"Sep 26 10:23P" (from the deploy listing). Now that is unfortunately only
half correct "Sep 26 10:23am" should be the correct time! I.e. there is
always a 'P' regardless whether pm or am... and it's not 24-hour clock
(which would be perferable for us).

Reply to this email directly or view it on GitHub:
#97 (comment)

from errbit.

the time thing is kinda weird, errbit defines :micro as

Time::DATE_FORMATS[:micro] = '%b %d %l:%M%P'
./config/initializers/time_formats.rb

which is for me, approximately now:

>> Time.now.strftime('%b %d %l:%M%P')
=> "Oct 01  8:22P"

but when i do the following:

>> 24.times.collect { |a| "%c" % (Time.now + a.hours).strftime('%b %d %l:%M%P')[-1] }.uniq
=> ["P"]

i.e. it's always P for me, btw it should really be 'pm' and 'am' (http://ruby-doc.org/core-1.9/classes/Time.src/M000314.html) and it seems that http://strfti.me/?f=%25B+%25d%2C+%25Y+%25P confirms that.

Doh! Next time i'll save myself the effort and check stackoverflow first: http://stackoverflow.com/questions/5149584/rubys-time-strftime-p-option-doesnt-work --> %P is broken in (ree-)1.8.7(-2011.03) and i should really be using 1.9.2-p180 .... ok, i'll do that :)

from errbit.

Ok, all fixed. I changed the migration you mentioned above, basically line 15 went from

 err.problem = app.problems.create

to

err.problem = app.problems.create(:_id => err.id)
err.problem.resolve! if err.resolved
err.problem.update_attribute(:issue_link, err.issue_link) rescue NoMethodError

then old links from old issues will keep working since the probems have the same id as the original errors that were linked in our tickets. Also the resolved flag was not being set on the problems --> from 101 tickets, went down to 56 (adding the _id to problem) to 7 (setting resolve! explicitly on the problem). And the tickets that we have already created, remained attached to the err (or rather problem).

Also, even though the rake tasks are invoked in the migration, then don't seem to be done correctly (caching within the migration?), anyway i executed

rake errbit:db:update_problem_attrs
rake errbit:db:update_notices_count

and everything was exactly the same (i.e. the latest date on the problems was back to the original values).

Thanks for the help!

from errbit.

One more thing i noticed is that on the err listing page (i.e. /errs), the last comment (if there was one) was shown -- now that doesn't happen? it was really helpful since you could see straight away if someone else has already commented .... simliar the ticket link that is now not shown :(

from errbit.

the fixes to the migration are on this commit --> gorenje@2263d31 (pull request would include 4 other commits)

from errbit.

see #98

from errbit.