Thanks all for the replies, we've been considering collapsing all those tables into a single one for "invalidate_content". Just getting a feel for it's use.
-Dew On Thu, May 3, 2018 at 9:59 AM, Steve Malenfant <[email protected]> wrote: > We haven't touched those tables @Cox. We use the built-in content > invalidation. > > On Tue, May 1, 2018 at 6:05 PM, Hongfei Zhang (hongfezh) < > [email protected] > > wrote: > > > @Dew - we did not touch job_result table. Thanks, -Hongfei > > > > On 5/1/18, 5:03 PM, "Dewayne Richardson" <[email protected]> wrote: > > > > @Hongfei > > > > What about the "job_result" table? It doesn't seem to be used at > all. > > > > - Dew > > > > On Tue, May 1, 2018 at 2:47 PM, Hongfei Zhang (hongfezh) < > > [email protected] > > > wrote: > > > > > Hi Dew/Jan, > > > > > > We made some minor changes in content invalidation which were using > > > Job/Status - specifically we: > > > 1. added back CANCELLED job_status and added a Cancel subroutine > in > > > API/Job.pm > > > 2. Exposed the cancel function via API endpoint DELETE > > > /api/$version/jobs/:id - which calls above cancel() > > > > > > > > > Thanks, > > > -Hongfei > > > > > > On 5/1/18, 4:27 PM, "Jan van Doorn" <[email protected]> wrote: > > > > > > I think they should be nuked. > > > > > > Rgds, > > > JvD > > > > > > > On May 1, 2018, at 2:04 PM, Dewayne Richardson < > > [email protected]> > > > wrote: > > > > > > > > I'm beginning to evaluate the Perl cleanup effort and noticed > > that > > > the > > > > *job_agent*, *job_status*, and *job_result* are minimally > used > > > (except for > > > > the "job" table which has the list of Purge Jobs"). I wanted > > to get > > > a feel > > > > for the usage outside of Comcast and what the sentiment is to > > those > > > tables > > > > (or not). > > > > > > > > > > > > > > > > -Dew > > > > > > > > > > > > > > > > > > >
