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/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/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/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
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.
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
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
- 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
refs https://github.com/TryGhost/Team/issues/3294
- The factory method for the Collection and validations should live close together based on our latest architectural direction
refs https://github.com/TryGhost/Team/issues/3167
- Having paging metadata is part of every API response and was missing from initial implementation
- The getAll method has all of the values as "static" as there's nothing to page on.
refs https://github.com/TryGhost/Team/issues/3167
- The core client (API) needs a way to pass in information without an ID when creating a new entity, handling it on service/repository layer makes the most sense.
- Used "require" syntax to import tpl/errors modules, otherwise TS compiler was complaining about type compatibility issues, this works as a temporary workaround and is tracked and an issue to improve in the future.
closes https://github.com/TryGhost/Team/issues/3166
- The collections service contains CRUD logic to manage collection entities through: save, getById, getAll, and destroy methods.
