day_planner 0.1.0.pre31 → 0.1.0.pre32
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/PLANS.md +0 -7
- data/README.md +7 -1
- data/app/models/day_planner/task.rb +0 -1
- data/lib/day_planner/base.rb +5 -0
- data/lib/day_planner/version.rb +1 -1
- metadata +1 -1
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA1:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: 1ff45c10b5a4bb3819d567e8eef31cb7fd1632c4
|
4
|
+
data.tar.gz: e5d25dd3784cb0f95b2dc57000ca80390ca8ae09
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: 60e0a44cee133a468dfa694798b1ef4e5b4783e670c7f0b4ca73269bc75f2f04f5860ddd526396452405b96642f105f2401d2aad73dd1446ecefc1c6433ded70
|
7
|
+
data.tar.gz: d622a3a1b158cd50896bd89938c0e5ef4eba03045657f5905a857288a9141251d4e4c4b0690b8bad083dbdd4ce6827364ec66f4225de46f3d92a5179c8a5c123
|
data/PLANS.md
CHANGED
@@ -8,13 +8,6 @@ This is basically a gimme as long as we're already recording stuff in a database
|
|
8
8
|
* Do delete any unfamiliar tasks (i.e. anything in day_planner_tasks that isn't listed in our schedule file)
|
9
9
|
* Don't reinitialize persistent events, just keep them on schedule. This helps especially if e.g. dealing with a pricy API -- why pull more often than needed?
|
10
10
|
|
11
|
-
### Log each tasks's history ###
|
12
|
-
HIGH PRIORITY: I want to be able to monitor the elaborate new scheduling algorithm appropriately. This needs to be optional, but it would be nice to have the ability to monitor at least how well the task adheres to the timeline.
|
13
|
-
* Optional generator task to create a table of task history whatnot? Check for it on initialize and then start writing to it if it's there.
|
14
|
-
* Read history, add method to calculate number of times task performed over timeframe.
|
15
|
-
* ActiveRecord::Base.connection.table_exists?('day_planner_task_log') welp then check for it
|
16
|
-
* new rails generator to create that migration
|
17
|
-
|
18
11
|
### Attempt some degree of control with multi-process instances ###
|
19
12
|
Not sure exactly how to do this.
|
20
13
|
* Store a record of the scheduler's execution status in a database? Then use that to avoid it being unnecessarily run in multiple threads?
|
data/README.md
CHANGED
@@ -80,7 +80,13 @@ If you'd like to log your tasks, go for it. Add logging thusly:
|
|
80
80
|
rails generate day_planner:log
|
81
81
|
rake db:migrate
|
82
82
|
|
83
|
-
This just adds an extra table entitled 'day_planner_log'. As long as the table's there, it'll log each task execution, as well as every instance in which DayPlanner activates.
|
83
|
+
This just adds an extra table entitled 'day_planner_log'. As long as the table's there, it'll log each task execution, as well as every instance in which DayPlanner activates.
|
84
|
+
|
85
|
+
It may be worth considering clearing the log on every launch. You can add such instruction to your schedule file:
|
86
|
+
|
87
|
+
DayPlanner.clear_log
|
88
|
+
|
89
|
+
Clear the log as the spirit takes you. Do what you do best.
|
84
90
|
|
85
91
|
## Contributing
|
86
92
|
|
@@ -16,7 +16,6 @@ module DayPlanner
|
|
16
16
|
fields = {}
|
17
17
|
fields[:name] = options.delete(:name) if options[:name]
|
18
18
|
fields[:interval] = options.delete(:every).to_i if options[:every]
|
19
|
-
# fields[:last_execution] = Time.parse("1/1/1")
|
20
19
|
|
21
20
|
task = DayPlanner::Task.create(fields)
|
22
21
|
end
|
data/lib/day_planner/base.rb
CHANGED
@@ -38,6 +38,11 @@ module DayPlanner
|
|
38
38
|
DayPlanner::Task.reset_table_sequence
|
39
39
|
end
|
40
40
|
|
41
|
+
def clear_log
|
42
|
+
ActiveRecord::Base.connection.execute("DELETE FROM #{DayPlanner::Log.table_name} WHERE true;")
|
43
|
+
DayPlanner::Log.reset_table_sequence
|
44
|
+
end
|
45
|
+
|
41
46
|
def schedule(options, &block)
|
42
47
|
raise ArgumentError, "Failed to pass an options hash" unless options.is_a?(Hash)
|
43
48
|
|
data/lib/day_planner/version.rb
CHANGED