Project

General

Profile

Feature #2532

pidFilter parameter for getLogRecords

Added by Rob Nahf over 10 years ago. Updated about 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Documentation
Start date:
2012-03-26
Due date:
% Done:

100%

Milestone:
CCI-1.0.0
Product Version:
*
Story Points:
Sprint:

Description

Add new filtering parameter to getLogRecords. Make sure API and client implementations updated, but not necessary for service implementations.

"Log aggregation is initially less visible than the other services,
but is important especially for MN operators and data contributors.
Ideally, log aggregation should also be useful to us for tracing
content access. To that end, it seems that we did omit a fairly
obvious use case for log aggregation, which is the ability to retrieve
log info for a PID (assuming appropriate permission). I suggest adding
another parameter to the CN to support matching the start of PIDs".

If PID is supplied, then it matches the start of PIDs in the log records. So for example, CN.getLogRecords(PID="dave") should match "dave", "dave.00.00", etc


Subtasks

Task #2533: update the d1_common_java interfacesClosedRob Nahf

Task #2534: update the libclient_javaClosedRob Nahf

Task #2535: update the d1_common_python interfaceClosedRoger Dahl

Task #2536: update d1_libclient_pythonClosedRoger Dahl

Task #2537: create d1_integration tests using pidFilterClosedRob Nahf

History

#1 Updated by Rob Nahf about 10 years ago

  • Status changed from In Progress to Closed
  • Target version set to Sprint-2012.21-Block.3.3

the parameter is included in specifications and interfaces. Not necessarily in the implementations (metacat, gmn). Integration tests written, as well.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 14.8 MB)