Daniel Hollas

> Note that for calcjobs the version of both core and plugin is also stored in the attributes. But since that is fixed, that doesn't suffer from the same problem...

I see, that is subtle indeed. So if I understand correctly, the approach in this PR *could* work for Processes, because you could modify aiida-core to add it to ProcessNode...

Yeah, that makes a lot of sense! I guess I don't even understand how caching works for Data node, or what even would be a purpose of that? I thought...

> I think this can be a very straightforward implementation, the hash is already stored in the extra, I didn't see why it is a problem to not store the...

I briefly went through the implementation and mostly makes sense to me. Now it got me thinking, should aiida-core use the same mechanism for invalidating caches, instead of forcing a...

Sorry, on a conference this week. Need to think this through a bit, I'll try to reply on Wednesday if I am able. By Friday the latest.

> Although it should properly "invalidate" existing caches since the hash of future processes with identical inputs will now be different, due to the changed CACHE_VERSION attribute, the stored hash...

> This is exactly the opposite motiviation for the feature we are discussing adding here, which is to give control to calcjob plugins to invalidate their hash if their implementation...

> I think we should add a similar attribute for the Parser. Yeah, unfortunate but reasonable. At some point I was also thinking about if we could somehow detect Parser/CalcJob...

> So maybe it would make more sense to move CACHE_VERSION to the CalcJob? +1 If we realize we need it to be more generic, we can always lift it...