Thanks again for your reply, Max!<br><br><div class="gmail_quote">On Sat, Apr 17, 2010 at 04:27, Max Kanat-Alexander <span dir="ltr"><<a href="mailto:mkanat@bugzilla.org">mkanat@bugzilla.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On 04/16/2010 05:55 AM, Yavor Nikolov wrote:<br>
> Well, maybe that's closest to what Kristis had in mind. But seems too<br>
> much bloating to me if we wrap each call to Bugzilla in eval and check<br>
> each time for errors (maybe not each function in Bugzilla is throwing<br>
> errors but for safety I'm assuming that it might throw one /some day in<br>
> some release/).<br>
<br>
</div> It's not bloat. As you can see by my comments below, only one statement<br>
in your code needed eval{}.<br></blockquote><div>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):<br>
my @ret_list = eval {<br> ...<br> my $user = Bugzilla::User->new( { name => $username } );<br> Bugzilla->set_user($user);<br> my $bug = Bugzilla::Bug->check($bugid);<br> ...<br>
...<br> ...<br> my $assignee_user = Bugzilla::User->new( {name => $resolution} );<br> ...<br> $bug->set_assigned_to($assignee_user);<br> ...<br> ...<br>
$dbh->bz_start_transaction();<br> ...<br> ... if (...) {<br> ...<br> $bug->set_status($new_status1);<br> ...<br> ... else {<br> ...<br> $bug->set_status($new_status4, $my_resolution);<br>
...<br><br> $bug->update();<br> $dbh->bz_commit_transaction();<br> <br> return 0;<br> ...<br> }; # eval<br> if ($@) {<br> my $err = $@;<br>
log_daemon_warn( undef, $err );<br> $dbh->bz_rollback_transaction() if $dbh->bz_in_transaction();<br> return 1, "Error while changing bug resolution: $err";<br> }<br>
else {<br> return @ret_list;<br> }<br><br>I suppose you'll suggest start_transaction is not needed here either.<br>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).<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Functions that don't throw errors now probably won't start throwing<br>
errors in the future.<br>
<div class="im"><br>
> OK. I found that Object::update has start/commit transaction block but<br>
> there are some other actions in Bug::update after that which I'm not<br>
> sure about (activity log, duplicates, etc, ...)... Looking at<br>
> process_bug.cgi I felt safer to wrap this in transaction block. (I'm not<br>
> sure what isolation level is being used).<br>
<br>
</div> You don't need to wrap it in a transaction.<br></blockquote><div>Great. Is it bad to to so? Imagine following scenario:<br>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).<br>
2. We call set_status (RESOLVED DUPLICATE M) and update for bug N - no errors raised here. All seems OK.<br>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.<br>
---<br>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).<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
> - imagine we have some bulk activity - adding comments, updating<br>
> status, resolution, etc. And same error message (e.g. invalid bug id)<br>
> may come out from different places. We may want to know if it's a<br>
> problem with duplicate bug id (DUPLICATE OF); or the main bug.<br>
<br>
</div> The error message from Bugzilla will tell you that. If it doesn't, you<br>
can file a bug requesting that Bugzilla throw a clearer error message.<br>
<div class="im"><br>
> - Or we may want to distinguish between more common user errors (bad<br>
> argument provided: resolution status name, bug id, username, etc);<br>
> security error; CodeError; or a more fatal one (database, etc.)<br>
<br>
</div> When you have a specific instance of wanting to do this, there will<br>
most likely be a way to handle it.<br>
<div class="im"><br>
> Good point (damn Perl... :-)) I got false impression that these have<br>
> been designed as part of language... But really that seems more like a<br>
> wish for future: <a href="http://dev.perl.org/perl6/rfc/63.pod" target="_blank">http://dev.perl.org/perl6/rfc/63.pod</a>,<br>
<br>
</div> Perl 6 is not the same language as Perl 5. (Confusing, I know.)<br>
<div class="im"><br>
> The point is that we want to see same result as if the committing user<br>
> itself has updated the bug.<br>
<br>
</div> Okay. Starting with Bugzilla 3.6, you could also write an Extension<br>
that would help you do what you want.<br></blockquote><div>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.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
> But maybe we could make that work if it's<br>
> possible to log-in as user with sudoer user and impersonate to someone<br>
> later - is it?<br>
<br>
</div> It might be possible, although sudoers can't impersonate admins. It's<br>
not possible via the WebService, currently, though, at all.<br>
<div class="im"><br>
> At first glimpse I can't see how to call<br>
> Bugzilla::BugMail::Send( $bugid, $vars ); either.<br>
<br>
</div> You would never call that yourself in the WebService--it does it for you.<br>
<div class="im"><br>
> I hope there is a better<br>
> object-oriented approach (i.e. proxy to look like just as the real<br>
> object) to call web service methods in Perl than passing around strings<br>
<br>
</div> The WebService is documented here:<br>
<br>
<a href="http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService.html" target="_blank">http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService.html</a><br>
<br>
It is not SOAP, if that is what you're asking. It is instead a simple<br>
series of functions that perform specific actions. Depending on what<br>
language you're using, there are various libraries that wrap Bugzilla's<br>
WebService API. For Perl there's BZ::Client:<br>
<a href="http://search.cpan.org/dist/BZ-Client/" target="_blank">http://search.cpan.org/dist/BZ-Client/</a><br></blockquote><div>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.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div class="h5"><br>
-Max<br>
--<br>
<a href="http://www.everythingsolved.com/" target="_blank">http://www.everythingsolved.com/</a><br>
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.<br></div></div></blockquote><div><br>Regards,<br>Yavor <br></div></div><br>