refs https://github.com/TryGhost/Arch/issues/95
Rather than storing all of the relations between the latest collection and
posts, we know that it contains all posts. This means we don't have to keep the
collections posts in sync. Instead we can fetch them from the posts table. This
saves a lot of work during recalculation.
refs https://github.com/TryGhost/Arch/issues/95
We're going to be treating the "latest" Collection as a "virtual" Collection
where we will hydrate the posts from the posts repository. This will allow for
more performant queries, and less work to keep the "latest" Collection in sync
refs https://github.com/TryGhost/Arch/issues/86
- When PostEditedEvent data contains no visible changes we can skip the matching collections update process alltogether. Each call to `updatePostInMatchingCollections` creates a transaction in addition to fetching all collections. There's no need to process anything when there are no relevant changes in the post edit!
refs https://github.com/TryGhost/Arch/issues/77
- During initial development we have missed to support collections update when tags are added to posts in bulk. It's especially valid usecase since we can define automatic collection with a filter containing not yet existing tags.
refs https://github.com/TryGhost/Arch/issues/47
This ensures that we only have collections which have a valid filter in terms of
- Valid NQL string
- Uses only properties which are valid to filter on
- Only has an empty filter in the case of the "latest" collection
refs https://github.com/TryGhost/Arch/issues/16
- When posts produce PostsBulkFeaturedEvent/PostsBulkUnfeaturedEvent the collections having a featured filter should update the posts belonging to them.
refs https://github.com/TryGhost/Arch/issues/16
- When posts produce PostsBulkUnpublishedEvent the collections having a published_at filter should update the posts belonging to them
refs https://github.com/TryGhost/Arch/issues/16
- When the bulk destroy is done on posts Collections need to know about the update and remove the stored posts from collections.
closes https://github.com/TryGhost/Arch/issues/62
Because there are many ways in which filters can rely on tags, we will just
recalculate all automatic collections for now, rather than attempting to do
optimised updates.
The PostRepository type was using `any` (an anti pattern) rather than
`PostCollection`, and we had optional properties, which are not really
optional. This cleans up the types and updates the tests alongside them.
refs https://github.com/TryGhost/Arch/issues/60
This will be used to update collections when a tag is deleted. Like the Post
events this should not be in the collections package, instead we should have
these as part of the tags and posts packages. These packages don't exist right
now, so I'm following the existing pattern.
refs https://github.com/TryGhost/Arch/issues/46
- Similarly to post filters, collection filters now support both 'tag' and 'tags' nql filter keys when defining a filter for related tag slugs. For example, both `tag:avocado` and `tags:avocado` would both be valid collection filters that would filter by the same 'slug' property of the tags assigned to a post.
- Along with these changes had to rework the tags property of the collection posts to match the shape used in post resources. Moved from:
`tags: ['bacon', 'broc']`
to
`tags:[{slug: 'bacon'}, {slug: 'broc'}]`
refs https://github.com/TryGhost/Arch/issues/16
- Some of the methods became unused due to moving the posts handling out of the collections service and cleaning up the event handling system.
refs https://github.com/TryGhost/Arch/issues/16
- The generic "UpdateAllCollections" logic should not be used as the mapped Post's delete/add/edit events should be sufficient in maintaining collection's state
refs https://github.com/TryGhost/Arch/issues/41
- When an new collection is created the relational "tags" filter is now picked up properly and appropriate posts matching the tag filter are assigned and stored in the collection. Example collection filter that is now supported: `tags:['bacon']`
- Additionally cleaned up returned collection post DTOs, so we return as little data as possible and add only the fields that are needed
refs https://github.com/TryGhost/Arch/issues/25
- When run against different DB Engines the returned order of collections belonging to a post is not consistent (SQLite vs MySQL). Having a primitive ordering by slug allows to keep the order compatible
https://github.com/TryGhost/Arch/issues/25
- This naming matches how the collection will be visible in the cards and how it's marketed. Naming it "index" even for internal purposes will get confusing.
closes https://github.com/TryGhost/Arch/issues/27
- We need a more convenient method of fetching posts belonging to a collection than by collection's "id". This change adds an alias to the existing endpoint `GET /collections/:id/posts/`. A non-valid ObjectID in the parameter is treated as a slug.
refs https://github.com/TryGhost/Arch/issues/25
- The built in index (soon -> "latest") collection does not require any filtering so that it could contain an index of all posts in the system. All other automatic collections should have a filter defined.
We couldn't decide on the best way to encode this in the database.
e.g. deletable: true? or type: internal? but type conflicts with the
storage of manual/automatic.
For now we can use this, and add something in future if we're finding problems
When we end up wiring this to the database, this generator will also ensure
uniqueness by appending/incrementing a number on the end of the slug. Long term
it would be good to offload this to a shared slug service, this could also
ensure that slugs are unique globally or between multiple tables, if desired
We require that slugs are unique as slugs can/are used for routing purposes and
act as an identifier for a resource. As this is a core business rule, we want
to encode it in the entity so that it can be unit tested, and be enforced
regardless of underlying persistence layer
refs https://github.com/TryGhost/Team/issues/3169
- With the new architecture all possible dependencies should be injected rather than required directly - this applies to the DomainEvents module as well.
refs https://github.com/TryGhost/Team/issues/3169
- This piece of logic handles the 'post.added' model event mapping to Collection's PostAddedEvent domain event and logic related to updating collections when the new post is added.
refs https://github.com/TryGhost/Team/issues/3169
- The collection entity properties used to be modified, which is not a good practice for logic encapsulation. Extracted editing logic to it's own method which can also contain validation logic when wrong data is passed when editing a collection.
refs https://github.com/TryGhost/Team/issues/3169
- When handling a single generic event the code becomes riddled with if statements to detect correct "data" that is being passed with the event. Switching to have a domain event per model event helps solving this problem and makes code more readable.
refs https://github.com/TryGhost/Team/issues/3169
- To make the coupling to Ghost's model events as loose as possible added a bridge that maps model events to domain events. These domain events it what the collections module can subscribe to to make necessary updates.
refs https://github.com/TryGhost/Team/issues/3428
- I'm taking an approach of adding specialized support for each event one-by-one.
- The post resource deletion event is the most straight forward and works same for both types of collections.
refs https://github.com/TryGhost/Team/issues/3423
- This is a convenience method that should allow fetching collections by their slug. It is a great developer experience for in case when fetching built-in collections like "featured" and "index", so can avoid an extra call to find the collection and it's ide one wants to use.
refs https://github.com/TryGhost/Team/issues/3423
- When querying for posts that belong to a collection we should be returning full post information just like we do for Posts API.
closes https://github.com/TryGhost/Team/issues/3170
- When resources that are related to automatic collection filter are updated the posts in collections should be updated as well.
- This change adds a super-basic way to track changes in post/tag/author resources and updated all automatic collections when any of those resources change. In the future we can optimize the update process to be more performant, but it's good enough for current needs
refs https://github.com/TryGhost/Team/issues/3170
- This implementation allows to create an automatic collection with a filter defining automatically populated posts that belong to a collection
- To populate collection using a filter the API client can send a `filter` property along with a collection request
- Filter values are compatible with the filters used in Content API (https://ghost.org/docs/content-api/#filter)
refs https://github.com/TryGhost/Team/issues/3260
- We need a way to remove posts form collections without fetching the whole collection's content. This API method allows to remove posts from manual collections by collection id and post id.
- As a response it returns up to date collection state without the removed post.
refs https://github.com/TryGhost/Team/issues/3260
- Whenever properties of the DTO are undefined they should be removed to avoid unintentional empty assignments to the stored collection
