# `MishkaBlog.PostCollection`
[🔗](https://github.com/mishka-group/mishka_blog/blob/v0.0.1/lib/mishka_blog/resources/post_collection.ex#L5)

Manages the many-to-many relationship between blog posts and collections with full version control.

This resource serves as the join table that associates blog posts with collections,
enabling posts to belong to multiple collections and collections to contain multiple posts.
Each record represents a collection membership, indicating that a post is included
in a specific collection.

The resource implements upsert functionality through the assign action, preventing
duplicate post-collection assignments while allowing efficient bulk updates.
The unique constraint on post_id and collection_id pairs ensures that each post
can only be assigned to a collection once, maintaining data integrity.

Post-collection associations are tracked through PaperTrail integration, recording
when posts are added to or removed from collections. This provides a complete
audit trail for content organization changes, essential for editorial workflows
and content management.

Access to this resource is controlled through policies that allow manipulation
either through the BlogPost or Collection resource relationships or by users with
administrative privileges. This ensures that collection membership can only be
modified by authorized actors.

# `t`

```elixir
@type t() :: %MishkaBlog.PostCollection{
  __lateral_join_source__: term(),
  __meta__: term(),
  __metadata__: term(),
  __order__: term(),
  aggregates: term(),
  calculations: term(),
  collection: term(),
  collection_id: term(),
  inserted_at: term(),
  post: term(),
  post_id: term(),
  post_in_any_state: term(),
  updated_at: term()
}
```

# `default_short_name`

# `input`

```elixir
@spec input(values :: map() | Keyword.t()) :: map() | no_return()
```

Validates that the keys in the provided input are valid for at least one action on the resource.

Raises a KeyError error at compile time if not. This exists because generally a struct should only ever
be created by Ash as a result of a successful action. You should not be creating records manually in code,
e.g `%MyResource{value: 1, value: 2}`. Generally that is fine, but often with embedded resources it is nice
to be able to validate the keys that are being provided, e.g

```elixir
Resource
|> Ash.Changeset.for_create(:create, %{embedded: EmbeddedResource.input(foo: 1, bar: 2)})
|> Ash.create()
```

# `input`

```elixir
@spec input(values :: map() | Keyword.t(), action :: atom()) :: map() | no_return()
```

Same as `input/1`, except restricts the keys to values accepted by the action provided.

# `primary_key_matches?`

---

*Consult [api-reference.md](api-reference.md) for complete listing*