[9.1] feat: use summary tables and triggers#8199
[9.1] feat: use summary tables and triggers#8199fstagni wants to merge 21 commits intoDIRACGrid:integrationfrom
Conversation
fstagni
force-pushed
the
table_summaries
branch
2 times, most recently
from
b98978f to
f32b961
Compare
fstagni
changed the title
fstagni
force-pushed
the
table_summaries
branch
6 times, most recently
from
abc0efc to
aaadeea
Compare
fstagni
force-pushed
the
table_summaries
branch
3 times, most recently
from
86a7cc4 to
d263910
Compare
fstagni
force-pushed
the
table_summaries
branch
2 times, most recently
from
d4d430d to
f492bc0
Compare
| if "Monitoring" in self.pilotMonitoringOption: | ||
| self.log.info("Committing PilotsHistory to Monitoring") | ||
| result = PilotAgentsDB().getSummarySnapshot() | ||
| sql = "SELECT * FROM PilotsHistorySummary ORDER BY GridSite, DestinationSite, Status, VO;" |
There was a problem hiding this comment.
why writing the query directly here ?
There was a problem hiding this comment.
Because it is the only place where we need it and I did not want to create a new method in the DB class. I understand it's not very elegant, but it's simpler and anyway DIRAC will keep using these hand-written queries for MySQL only.
| Return Distinct Values of Owner job Attribute in WMS | ||
| """ | ||
| return cls.jobDB.getDistinctJobAttributes("Owner", condDict, older, newer) | ||
| return cls.jobDB._query("SELECT DISTINCT Owner FROM JobsHistorySummary") |
There was a problem hiding this comment.
I am not sure that there is any benefit in these changes, given that the Job table has an index on all these parameters. I just tried on the LHCb production instance, it returns the answer in 0.021s for Owner for example
There was a problem hiding this comment.
It will probably be even less for the summary table. I agree with you that it's minor improvement anyway.
|
|
||
| -- summary for JobsHistory | ||
|
|
||
| DROP TABLE IF EXISTS `JobsHistorySummary`; |
There was a problem hiding this comment.
From the operational point of view, how do you see that happening ? You need to fill in that table with an initial content representing the current state. That will take for ever and require a downtime no ?
There was a problem hiding this comment.
For everyone but LHCb this is just one more thing to be done during the update downtime.
For LHCb:
- the current query (which is what you would theoretically want to do) takes at most 15 minutes, not "for ever"
- But anyway, I have something in mind to avoid that, but no need to write it down here.
fstagni
force-pushed
the
table_summaries
branch
4 times, most recently
from
655119a to
581f099
Compare
fstagni
force-pushed
the
table_summaries
branch
3 times, most recently
from
10759e7 to
e33c0bb
Compare
…aries for StatesAccounting) F
fstagni
changed the title
3 participants
BEGINRELEASENOTES
*WMS
NEW: added tables of summaries and triggers to fill their content
ENDRELEASENOTES