Removing components using web app

[katalina-w 44]

Hi, I'm working some more on caching, and I just discovered that it looks like when a component is deleted from an asset version using the web application, it does not trigger an event to the topic ftrack.location.component-removed. Am I missing something or is this correct? We are on version 3.3.25.

 

Thanks!

Kat

[Mattias Lagergren 145]

Hi Kat,

Quote

Hi, I'm working some more on caching, and I just discovered that it looks like when a component is deleted from an asset version using the web application, it does not trigger an event to the topic ftrack.location.component-removed. Am I missing something or is this correct? We are on version 3.3.25.

You are correct, not ftrack.location.component-removed or an ftrack.update event. I will raise this with my colleagues and see what we can do about it

[katalina-w 44]

Thanks, Mattias!! It also looks like ftrack.location.component-added events are not sent when a component is added using the legacy API. Is this intentional? I can work around it, as all things *should* be converted to the new API anyway, but I was cheating with some farm processes.

 

Kat

[Mattias Lagergren 145]

16 hours ago, katalina-w said:

It also looks like ftrack.location.component-added events are not sent when a component is added using the legacy API. Is this intentional?

That is very odd, from browsing the code it looks like the legacy api should emit both 'ftrack.location.component-added' and 'ftrack.location.component-removed'.

[katalina-w 44]

Hi Mattias, any update about the ftrack.location.component-removed topic not being emitted?

Thanks,
Kat

[Mattias Lagergren 145]

On 9/8/2016 at 1:06 AM, katalina-w said:

Hi Mattias, any update about the ftrack.location.component-removed topic not being emitted?

Thanks,
Kat

Hi Kat,

I think you're discussing this with Lucas on our support and he will follow up with you separately. For future reference, the issue is not as straightforward as we would have hoped as removing a component via the Web UI does not remove the data. All other places where we emit component-added|component-removed is done after the data has been managed.

We're looking into different possibilities here like removing the feature to remove the component from the web UI and replace it with an optional Action that can be downloaded and used.

[Martin Pengelly-Phillips 29]

@Mattias Lagergren I'm interested in this also. At the very least, shouldn't an ftrack.update event be issued which would allow the caching case?

@katalina-w Are you running your own media server by any chance? If so, I would guess you could emit the event yourself there.

[katalina-w 44]

@Martin Pengelly-Phillips - Not running our own media server. I've figured my issue out for the most part, but either the disabling of deleting components through the web app or an emission of some kind of event would be best for caching.

[Mattias Lagergren 145]

On 9/12/2016 at 4:38 PM, Martin Pengelly-Phillips said:

@Mattias Lagergren I'm interested in this also. At the very least, shouldn't an ftrack.update event be issued which would allow the caching case?

If we just look at the components tab widget, would removing the "Remove" button and having an action to remove components solve your issue?

[Martin Pengelly-Phillips 29]

Quote

If we just look at the components tab widget, would removing the "Remove" button and having an action to remove components solve your issue?

 Like this

Seems like more work as have to run and maintain another action...  

However, my main interest was whether there are situations where deletion of an entity in the system is not causing a relevant event to be emitted (for cache invalidation purposes). So long as we can guarantee that relevant events are emitted when database state changes, I'm not too fussed.

[Mattias Lagergren 145]

18 minutes ago, Martin Pengelly-Phillips said:

However, my main interest was whether there are situations where deletion of an entity in the system is not causing a relevant event to be emitted (for cache invalidation purposes). So long as we can guarantee that relevant events are emitted when database state changes, I'm not too fussed.

I agree, and I've made sure that we have a ticket for adding events on changes to the component model.

[Martin Pengelly-Phillips 29]

Great to hear - thanks!