Loading of dependencies prevents delete

[aecker]

I don't know when this was introduced, but basically the current mechanism of loading table dependencies effectively prevents me from deleting anything in our common schemas. The reason is that the recursive loading of dependencies will eventually hit a schema of some other user for which I don't have access to the code, i.e. cannot activate it.

It used to be implemented in a way that if there were no tuples in other schemas affected it would delete and cascade just fine. Does anyone know when and why this behavior changed? It's kind of crucial to restore the old behavior since we have a lot of people basing their analyses on a common schema and it's impossible to keep all of those people's code somewhere around just for the purpose of loading dependencies that are completely irrelevant.

[ahoenselaar]

This has been a big concern of mine for a while now. It seems like you can hold whole tables hostage by referencing them in your own private schemata that other people don't have access to.

[aecker]

It didn't use to be like that a while ago. We've been using this scheme just fine for a long time. Only when I updated recently I started running into these issues. Also, I don't see why it should be like that. In principle, DJ should be able to create a dj.Table from the existing database tables without an explicit corresponding relvar class in the Matlab path.

[dimitri-yatsenko]

Yes, there is also a slight problem with erd related to this. I will fix it soon with improved handling of schema crossings. Will include in 2.6.11.

[dimitri-yatsenko]

Pushed the fix on master: f4f9b2c.
Closing.