DDEX update/delete #8251
DDEX update/delete #8251
Conversation
|
…ith no resource files if they were previously sent
…eave validation to the parser + the sdk
michellebrier
force-pushed
the
mbrier/proto-1729/ddex-golang-crud
branch
from
9a307dc
to
593603e
Compare
…ed in XML. NOTE: not sure what the filename looks like for PurgeReleaseMessages so I'm not sure if the crawler will correctly handle these types of messages. Need real examples to test with
| if releaseIDNode == nil { | ||
| return fmt.Errorf("no <ReleaseId> found") | ||
| } | ||
| releaseIDs := getReleaseIDs(releaseIDNode) |
There was a problem hiding this comment.
parse all known release IDs (GRid, ISRC, ICPN) in a <ReleaseId> node. When required, as is here, try each of these IDs when searching the releases collection until the first match.
The _id in a releases document is the ID we pull from the filename. We don't actually know which ID type this corresponds to and in the examples we have, there are often multiple ID types listed in the <ReleaseId> node.
Description
Parse updates by
is_update = trueif there is an existing release. Parse the new message as usual and replace the old release in the db. Ifis_updateis true, the publisher will issue anupdateTrack/updateAlbumvia the sdk rather than an upload.Accept 2 ways to indicate a takedown:
NewReleaseMessagewith no deal. If the release ID exists in the releases collection, takedown the release. If not, mark thisNewReleaseMessageas invalid (it's not a takedown as far as we can tell and should have a deal)PurgeReleaseMessage. I am not sure what the filenames are for these types of messages so not sure this will 100% work with the crawler (e.g. if there's 1 release ID to be purged perPurgeReleaseMessageand it's specified in the filename then it's good to go, but if there are many IDs to takedown perPurgeReleaseMessage, we need to rethink how we use the ID from the filename as the releaseID for the document in the releases collection). Need real examplesHow the parser takes down a release:
If the release has been published, set the
release_statustoawaiting_delete. The publisher then polls this and deletes the track/album via the sdk. If the release is awaiting publishing, set therelease_statustodeleted. The publisher will no longer poll this release for publication in the future.Also remove all redundant types in the publisher that are already specified in the parser.
How Has This Been Tested?
TODO