Project

General

Profile

Actions

Defect #27165

closed

Delete_all_members

Added by Enrique Vera over 6 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Projects
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
Invalid
Affected version:

Description

The method delete_all_members in the model Project is the next:

def delete_all_members
    me, mr = Member.table_name, MemberRole.table_name
    self.class.connection.delete("DELETE FROM #{mr} WHERE #{mr}.member_id IN (SELECT #{me}.id FROM #{me} WHERE #{me}.project_id = #{id})")
    Member.delete_all(['project_id = ?', id])
end

I was doing some test capturing the destroy event on a member patch and I realized that the event on this patch was only ran in some members.

The question is, why we have to do a class.connection to delete the member_roles and then run a member.delete_all if we have connected the models correctly.

I proved with this:

def delete_all_members
    me, mr = Member.table_name, MemberRole.table_name
    Member.destroy_all(['project_id = ?', id])
end

and the results were ok. Is there something that I don't know of it's a defect?

Thanks!

Actions #1

Updated by Holger Just over 6 years ago

When using destroy_all (or destroy) on a model, what happens is that Rails first fetches the record from the database, destroys it and runs any defined callbacks. If you have a lot of members, this can be very expensive.

With the way this is done in Redmine right now, it deletes the necessary records from the database directly with two DELETE SQL statements without first fetching the records them and creating ActiveRecord model instances for each of them.

Actions #2

Updated by Toshi MARUYAMA over 6 years ago

  • Description updated (diff)
Actions #3

Updated by Go MAEDA about 4 years ago

  • Status changed from New to Closed
  • Resolution set to Invalid

Closing this issue because this is not a defect but a question.

Actions

Also available in: Atom PDF