Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor PastIteration mounting process #379

Merged
merged 3 commits into from
Sep 14, 2018
Merged

Conversation

andrerpbts
Copy link
Contributor

It was full of N+1 queries, and letting the things very slow

@akitaonrails akitaonrails temporarily deployed to cm-fulcrum-pr-379 September 8, 2018 02:44 Inactive
@andrerpbts andrerpbts temporarily deployed to cm-fulcrum-pr-379 September 8, 2018 15:07 Inactive
@andrerpbts andrerpbts added the WIP label Sep 8, 2018
@andrerpbts andrerpbts changed the title Refactor PastIteration mounting process [WIP] Refactor PastIteration mounting process Sep 8, 2018
@andrerpbts andrerpbts temporarily deployed to cm-fulcrum-pr-379 September 8, 2018 18:03 Inactive
@andrerpbts andrerpbts changed the title [WIP] Refactor PastIteration mounting process Refactor PastIteration mounting process Sep 8, 2018
@andrerpbts andrerpbts removed the WIP label Sep 8, 2018
@andrerpbts
Copy link
Contributor Author

@akitaonrails @talyssonoc @adbatista There's a Review App up to tests.

Please note, since it's rebased with master, it is running with all those dependencies updated. Lets try to merge it on monday, please.

@akitaonrails akitaonrails temporarily deployed to cm-fulcrum-pr-379 September 8, 2018 20:33 Inactive

def stories_from(start_at, end_at)
stories.select do |story|
story.accepted_at >= start_at && story.accepted_at <= end_at
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't it better to do these conditionals with a query instead of directly in Ruby side?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dunno, I moved from a query because it was doing a lot of queries to get all this...

Only if we have a query to bring grouped those stories by start/end_at...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔

def length
(days_since_project_start / iteration_length_in_days).floor
end

def iteration_length_in_days
@project.iteration_length * 7
project.iteration_length * 7
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we're already here, what do you think about extracting the 7 to a DAYS_IN_A_WEEK constant?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

project
.stories
.with_dependencies
.where('accepted_at >= ? AND accepted_at <= ?', start_date, end_date)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Almost, but for just one past_iteration...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.with_dependencies
.where("state != 'accepted' OR accepted_at >= ?", current_iteration_start)
.order('updated_at DESC')
.limit(ENV['STORIES_CEILING'].presence&.to_i)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about extracting the ENV['STORIES_CEILING'].presence&.to_i to a method?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want to understand why this ceiling is there?

Active stories need to be limited?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm removing this. We are lazy loading done stories nowadays.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As spoke offline, we won't need this limit anymore.

.stories
.with_dependencies
.where(state: 'accepted')
.where.not(accepted_at: nil)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that chaining where calls will create an AND instead of an OR, right? If so, does it make sense to have stories that are accepted but have no accepted_at value? 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, makes sense, but I would keep it to prevent any possible inconsistence. It reflects exactly the kind of stories I'm expecting in the filter method above.

@andrerpbts andrerpbts temporarily deployed to cm-fulcrum-pr-379 September 10, 2018 13:05 Inactive
@stories ||= @project.stories.where(
'accepted_at >= ? AND accepted_at <= ?', @start_date, @end_date
)
@points ||= stories.to_a.map(&:estimate).compact.sum
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not stories.sum(:estimate) ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not every story has value in estimate, so I'm doing a map, compacting to remove nil values, and summing after.

I can change if you have a better approach...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just for clarification:

to_a here is only to always ensure we are doing it in an array, never into database. I'm avoiding queries here...

@andrerpbts andrerpbts temporarily deployed to cm-fulcrum-pr-379 September 10, 2018 20:18 Inactive
end_date: end_date,
project: @project,
iteration_number: iteration_number + 1)
start_at = start_date(iteration_number)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rodrigovirgilio apply beginning_of_day and end_of_day in those methods

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Applied a39d2c9

@rodrigovirgilio rodrigovirgilio temporarily deployed to cm-fulcrum-pr-379 September 12, 2018 13:56 Inactive
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants