[Fwd: Re: [scmbug-users] Error on changing status of bugs with Bugzilla 3.4.x]

Sat Apr 17 07:21:12 UTC 2010

Thanks again for your reply, Max!

On Sat, Apr 17, 2010 at 04:27, Max Kanat-Alexander <mkanat at bugzilla.org>wrote:

> On 04/16/2010 05:55 AM, Yavor Nikolov wrote:
> > Well, maybe that's closest to what Kristis had in mind. But seems too
> > much bloating to me if we wrap each call to Bugzilla in eval and check
> > each time for errors (maybe not each function in Bugzilla is throwing
> > errors but for safety I'm assuming that it might throw one /some day in
> > some release/).
>
>         It's not bloat. As you can see by my comments below, only one
> statement
> in your code needed eval{}.
>
Agreed for this case. A bit simplified code of the function which raised the
question here is something like that (I know we can merge all these 3-4
set_status calls into 1 - but let's imagine we have several of them):
         my @ret_list = eval {
        ...
        my $user = Bugzilla::User->new( { name => $username } );
        Bugzilla->set_user($user);
        my $bug = Bugzilla::Bug->check($bugid);
        ...
        ...
        ...
                my $assignee_user = Bugzilla::User->new( {name =>
$resolution} );
        ...
                $bug->set_assigned_to($assignee_user);
        ...
        ...
            $dbh->bz_start_transaction();
        ...
        ... if (...) {
        ...
            $bug->set_status($new_status1);
        ...
        ... else {
        ...
            $bug->set_status($new_status4, $my_resolution);
        ...

            $bug->update();
            $dbh->bz_commit_transaction();

            return 0;
        ...
        }; # eval
        if ($@) {
            my $err = $@;
            log_daemon_warn( undef, $err );
            $dbh->bz_rollback_transaction() if $dbh->bz_in_transaction();
            return 1, "Error while changing bug resolution: $err";
        }
        else {
            return @ret_list;
        }

I suppose you'll suggest start_transaction is not needed here either.
Is there anything bad in particular if we wrap multiple statements in eval
block? I know Kristis opened that request to ask for better alternative but
I still can't see why calling eval multiple times is cleaner (In case we
don't need to do anything special on these errors nor to customize error
message).

>        Functions that don't throw errors now probably won't start throwing
> errors in the future.
>
> > OK. I found that Object::update has start/commit transaction block but
> > there are some other actions in Bug::update after that which I'm not
> > sure about (activity log, duplicates, etc, ...)... Looking at
> > process_bug.cgi I felt safer to wrap this in transaction block. (I'm not
> > sure what isolation level is being used).
>
>         You don't need to wrap it in a transaction.
>
Great. Is it bad to to so? Imagine following scenario:
1. We're already in transaction for some reason (e.g. bugzilla throwed error
in the middle of transaction and didn't rollback since it's in eval block.
Could be other reason too).
2. We call set_status (RESOLVED DUPLICATE M) and update for bug N - no
errors raised here. All seems OK.
3. Something else goes wrong later (e.g. dealing with another bug -
Bug->check($user)). As result: bz_rollback_transaction is called (e.g. by
ThrowUserError outside eval block; or we quit/or abort scmbug deamon). In
fact - even if nothing fails - transaction is not committed either.
---
Finally: we have the considered successful update of bug N not reflected in
bugzilla database. (I just tested that and the result is as bug N is in fact
not updated as I suspected).

> >  - imagine we have some bulk activity - adding comments, updating
> > status, resolution, etc. And same error message (e.g. invalid bug id)
> > may come out from different places. We may want to know if it's a
> > problem with duplicate bug id (DUPLICATE OF); or the main bug.
>
>         The error message from Bugzilla will tell you that. If it doesn't,
> you
> can file a bug requesting that Bugzilla throw a clearer error message.
>
> >  - Or we may want to distinguish between more common user errors (bad
> > argument provided: resolution status name, bug id, username, etc);
> > security error; CodeError; or a more fatal one (database, etc.)
>
>         When you have a specific instance of wanting to do this, there will
> most likely be a way to handle it.
>
> > Good point (damn Perl... :-)) I got false impression that these have
> > been designed as part of language... But really that seems more like a
> > wish for future: http://dev.perl.org/perl6/rfc/63.pod,
>
>         Perl 6 is not the same language as Perl 5. (Confusing, I know.)
>
> > The point is that we want to see same result as if the committing user
> > itself has updated the bug.
>
>         Okay. Starting with Bugzilla 3.6, you could also write an Extension
> that would help you do what you want.
>
Seems a nice feature! But that means we'll need to maintain these
extensions, which will rely on the Perl API - pretty much same low-level
dependency on Bugzilla we have now in scmbug.

>
> > But maybe we could make that work if it's
> > possible to log-in as user with sudoer user and impersonate to someone
> > later - is it?
>
>         It might be possible, although sudoers can't impersonate admins.
> It's
> not possible via the WebService, currently, though, at all.
>
> > At first glimpse I can't see how to call
> > Bugzilla::BugMail::Send( $bugid, $vars ); either.
>
>         You would never call that yourself in the WebService--it does it
> for you.
>
> > I hope there is a better
> > object-oriented approach (i.e. proxy to look like just as the real
> > object) to call web service methods in Perl than passing around strings
>
>         The WebService is documented here:
>
>
> http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService.html
>
>        It is not SOAP, if that is what you're asking. It is instead a
> simple
> series of functions that perform specific actions. Depending on what
> language you're using, there are various libraries that wrap Bugzilla's
> WebService API. For Perl there's BZ::Client:
> http://search.cpan.org/dist/BZ-Client/
>
Thanks for that reference. I asked about something like BZ::Client imagining
that this could be automatically generated from WS definition - I want most
of code look the same /no matter if it's direct Bugzilla Perl call or via
web service/. I didn't know it doesn't support SOAP - maybe that means lack
of self-description which clarifies my automatic proxy generation question.

>
>        -Max
> --
> http://www.everythingsolved.com/
> Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
>

Regards,
Yavor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20100417/bbfc20a9/attachment.html>