Have post_meta owned by a single post object throughout the process

[AramZS]

No description provided.

[boonebgorges]

This could be a major improvement, but it needs deeper thought along a couple lines:

• Which object would be the "canonical" object? We can look at id_for_comments for some guidance. But the problem is that not every PF item will go through all three lifecycle stages: pf_feed_item, nomination, post.
• Related, we need to be sure that the canonical object is not one that can be deleted. By contrast, an item that comes through Nominate This may first be a nomination and then a post, and you can then go back and delete the nomination object without affecting the post.
• Are there pieces of metadata that might be expected to change through the lifecycle, in such a way that they couldn't be stored on a single post object? For example, is source-related data (item_author, item_date, source_title, etc) immutable? Aren't there stages in the process where it's opened up for editing? Should those edits apply to all stages of the lifecycle? How about something like pf_word_count, which is calculated automatically for nominations run through transition_to_readable_text() and thus is accurate for the nomination object, but may no longer be correct once it's promoted to post?

To me, this gestures toward a deeper structural change in PF, which is:

• We introduce a new, immutable post type pf_item or the like.
• Comments and most metadata are associated with that object, and that object only; when the content is needed to display on a pf_feed_item or nomination, it's pulled from the associated pf_item.
• pf_item posts are not exposed in the interface, and are not directly deletable. We would only consider deleting them if all related post, pf_feed_item, nomination objects were also deleted. (This would be particularly necessary for pf_feed_item - old feed items ought to be cleaned up on a schedule, and pf_item would have to be part of this in order to avoid database bloat)
• We would need a migration tool to create pf_items out of existing PF content, and/or a compatibility layer.
• Lots of internal plumbing would need to be rebuilt, though much of that would involve simplification, since much of the existing content-copying would no longer take place.

I'm tentatively putting this in a milestone to talk over with the team.