Trying to add the same YouTube URL twice causes a primary key violation

from a #ux perspective, seems like that should actually work, imho. if i have 500 videos in the system, and i try to enter a duplicate, seems like the system should simply recognize the old uri and send it through. otherwise, i'll get an error now, and need to sift through dozens or more pages of thumbnails to hopefully find the right one. fail. especially considering that there's no such restriction on uploading the same file twice (or a dozen times).

in early discussions of media, we'd actually wanted to have the media browser accept uri's rather than fid's, as this would then allow that by default. and, in fact, that's how it was originally implemented. not sure where along the way we changed that.

my idea would be to either fix media to allow accepting either an fid or a uri, or to have a fetched url translate to the correct fid if it already exists. because yes, obviously we don't want to cause a primary key violation.

+1. And when we have access control, imagine if two users try to link to the same video. That's actually an even scarier case, since it's not like we can rename the youtube URI. It would require a core change to "un-unique" the uri of course, but maybe we would need to. I'm not sure why it needs to be unique anyway. For the time being, I think this patch is worth committing though, even if it is a gross UX violation because the current state is much worse.

-J

well, if this blocking a release, let's go with it. i don't want to do an rc till we get this resolved in a better way though.

Subscribe.

Subscribe.

FYI for subscribers, #1213184: Allow YouTube videos to be re-used was able to remove the temporary fix added here now that file_uri_to_object() allows you to reuse existing files.