search

ynput / ayon-backend

Server codebase with API access to AYON
Apache License 2.0
22 stars 17 forks source link

Events: Trigger event when parent changes #428

Closed iLLiCiTiT closed 1 week ago

iLLiCiTiT commented 2 weeks ago

Story

An event is not triggered when parent of entity changes so it is not possible to capture that change.

Problems

Listening to entity changes for e.g. sync can't propagate parent changes properly now.

Proposal

This might be a little bit complicated. We have to consider that we can't move entities under different project.

Considering these changes

These changes should not happen so it is questionable if make sense to bother?

Question is what topic would be triggered? Folders can have folder parent, and if not set, it is project. Version has product as parent, but also can belong under task (is not parent just information). There are 2 options for topic entity.{entity type}.parent_changed or entity.{entity type}.{parent type}_changed, first might be confusing for version second for folder. Version would have entity.version.task_changed and a) entity.version.product_changed or b) entity.version.parent_changed. Folder a) entity.folder.parent_changed or b) entity.folder.folder_changed. (This monologue can be removed)

TODO

martastain commented 2 weeks ago

@iLLiCiTiT

folder being moved under different folder (under project)

entity.folder.parent_changed makes sense as the respective field is called parent_id

task being moved under different folder

both entity.task.folder_changed and entity.task.parent_changed makes sense, folder_changed is probably a better idea since the respective column in the database is folder_id and most importantly

version being moved to task

version is NOT a child of a task, it is a child of product, so to be explicit we should have both product_changed and task_changed. As you mentioned, it is not used, but we should be explicit about the entity type.

BigRoy commented 2 weeks ago

This would introduce many more events - no? Or can we 'batch' produce the event for all children at once? Instead of an event per child? I'm just wondering whether it wouldn't just make sense that whatever that processes the events takes care of the children itself (like "something changed" and then if that change may affect the children in a way relevant to that processor that it handles that itself).

It'd require to listen to changes of all entities however - instead of just the child entity (if that's what we're doing anywhere)

iLLiCiTiT commented 2 weeks ago

This would introduce many more events - no? Or can we 'batch' produce the event for all children at once? Instead of an event per child? I'm just wondering whether it wouldn't just make sense that whatever that processes the events takes care of the children itself (like "something changed" and then if that change may affect the children in a way relevant to that processor that it handles that itself).

It'd require to listen to changes of all entities however - instead of just the child entity (if that's what we're doing anywhere)

Same amount of events, with different topics.

BigRoy commented 2 weeks ago

I see - so these children already were getting events - it was just unclear that it was a change in their parent. In that case, 👍