Skip to content
This repository has been archived by the owner on Mar 26, 2024. It is now read-only.

Add: Prune reports that match a specific status #311

Closed
wants to merge 5 commits into from
Closed

Add: Prune reports that match a specific status #311

wants to merge 5 commits into from

Conversation

Nold360
Copy link

@Nold360 Nold360 commented Feb 1, 2015

Hi,

I've added the possibility to prune reports based on their status.
F.e. it's now possible to prune only reports that have the status "unchanged".

Examples:
RAILS_ENV=production bundle exec rake reports:prune unit=mon upto=1 condition=is status=unchanged
RAILS_ENV=production bundle exec rake reports:prune unit=mon upto=1 condition=not status=changed

Since this is the first time I've been codeing ruby, the changes will be most likely not that nice. I hope you like the feature anyway.

Best Regards,
Nold

errors << "I don't know that condition. Valid conditionss are: #{known_conditions}"\
end
else
condition = "!="
Copy link
Owner

Choose a reason for hiding this comment

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

Make this not instead of !=

@sodabrew
Copy link
Owner

sodabrew commented Feb 1, 2015

This is awesome! A few comments inlined above.

@Nold360
Copy link
Author

Nold360 commented Feb 1, 2015

Hi, thanks a lot for your comments.
I've changed everything you noted.

transaction do
old_report_ids = self.reports.where('reports.time < ?', cutoff).pluck(:id)
old_report_ids = self.reports.where("reports.time < \"#{cutoff}\" and reports.status #{condition} \"#{status}\"").pluck(:id)
Copy link
Owner

Choose a reason for hiding this comment

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

I missed this one, same change as in the other file:
.where("reports.time < ? AND reports.status #{condition} ?", cutoff, status)

@Nold360
Copy link
Author

Nold360 commented Feb 1, 2015

Fixed that, too.


if condition = ENV['condition']
unless conditions.has_key?(condition)
errors << "I don't know that condition. Valid conditionss are: #{known_conditions}"\
Copy link
Owner

Choose a reason for hiding this comment

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

extra 's' on conditions.

@sodabrew
Copy link
Owner

sodabrew commented Feb 2, 2015

The default behavior should be to delete reports of any status older than the given date, but I think the way the queries are written, you must supply a status, otherwise it won't delete anything?

@Nold360
Copy link
Author

Nold360 commented Feb 2, 2015

Cleanup done.

The default behavior is just as it has been before. If you don't specify status & condition, it will become:
... AND reports.status != ""

which will match every status in that table.

@sodabrew
Copy link
Owner

sodabrew commented Feb 2, 2015

Oh, gotcha. I would worry about a performance impact from this; the reports table tends to be huge.

The index covering reports.status has node_id in the middle, so the index wouldn't be usable here. In db/schema.rb:

add_index "reports", ["time", "node_id", "status"], :name => "index_reports_on_time_and_node_id_and_status"

@Nold360
Copy link
Author

Nold360 commented Feb 2, 2015

Hm, I'm not really into databases, so I can't tell.
We could change the code, so if no status is specified, the whole "AND reports.status ..." stuff wouldn't even be in the query... But I don't really know how to make that as nice as possible..

@Nold360
Copy link
Author

Nold360 commented Feb 2, 2015

We could change the default values for status and/or condition to "nil" and build the query in a if-condition f.e.:
if ! condition && ! status
query_string = ("reports.time < ?", cutoff)
else
query_string = ("reports.time < ? AND reports.status #{condition} ?", cutoff, status)
end

I don't know if the syntax for the strings is correct, but that could be the way to go.

@bwitt
Copy link
Collaborator

bwitt commented Aug 22, 2018

@Nold360 hi thanks for the feature! this sounds really great but I notice your source repo has disappeared! if you want to work on this some more I can help

@ZeroPointEnergy
Copy link
Collaborator

Since this branch is no longer around I took the liberty of rebasing it and creating a new PR where we can actively work on the feature. @Nold360 thanks again for the contribution and sorry it took so long. The new PR is #378

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants