Hi Kristis,
(1) Replacing bz_{lock,unlock}_tables with
bz_{start,commit,rollback}_transaction prevented the error from occurring
and seemed updating to RESOLVED FIXED worked fine. (I haven't tested other
scenarios).
(2) Anyway - I have implemented status/resolution updating using Bugzilla
perl API instead of direct database updates (seems more robust approach
otherwise I'm afraid we may cause database corruption if database schema
changes in future bugzilla versions /or maybe even this one/).
I'll upload the patch for (2) soon. (I just want to add my changes in
is_latest_version block since in current version I've probably broken some
old version compatibility). So far things seem to work OK In my environment
(tested changing to RESOLVED FIXED, ASSIGNED, ASSIGNED <user>, REOPENED,
DUPLICATE <dup-id>).
* Looking at scmbug Bugzilla.pm tracker code (and the modified method in
particular) - things are getting much bloated with these many
version-specific if/else if cases. I just wonder - wouldn't it be better to
just refactor version-specific code as separate sub-classes (the right one
instantiated by Daemon depending on specified version; or on specified class
name)? That would make things look simpler and easier to maintain - at least
for the most recent bugtracker versions.
Regards,
Yavor
On Fri, Mar 26, 2010 at 21:31, Yavor Nikolov <[email protected]>wrote:
> Hi Kristis,
>
> On Fri, Mar 26, 2010 at 21:15, Kristis Makris <[email protected]> wrote:
>
>> Hi Yavor,
>>
>> This is a big mistake on my part. I'm sorry.
>>
>> I thought that the status resolution work needed was already included in
>> the patches from Elias and Uditha. I was not aware of the fact that
>> bz_lock_tables was causing problems.
>>
>> On Fri, 2010-03-26 at 18:09 +0200, Yavor Nikolov wrote:
>> > Sorry for the wrong subject from initial report of this issue.
>> >
>> > Seems bugzilla 3.2+ removed bz_lock_tables in it's code and is
>> > handling database changes in
>> > bz_start_transaction/bz_commit_transaction blocks.
>> >
>> > I can see some earlier complains for this problem.. but it has been
>> > announced that v0.26.17 is supporting status changes for bugzilla 3.4
>> > now.
>>
>> Do you recall where ? I can't find it any report related to
>> bz_lock_tables in the issue-tracker.
>>
> Google for scmbug and bz_lock_tables may help for this. In particular I see
> following is related:
> http://permalink.gmane.org/gmane.comp.bug-tracking.scmbug.user/2106
> However Alex's patch has just commented these calls to bz_lock_tables. I'm
> not sure what would be the best way to handle this - but at least seems a
> better idea to add bz_start_transaction/bz_commit_transaction as replacement
> of removed bz_lock*/bz_unlock* statements. Something similar has been
> mentioned here:
>
> http://bugzilla.org/cgi-bin/mj_wwwusr?user=guy.pyrzak%40gmail.com&passw=&list=developers&brief=on&func=archive-get-part&extra=200703/31
>
> Regards,
> Yavor
>
_______________________________________________
scmbug-users mailing list
[email protected]
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
