Multiple conflicting views for the same table when using Single Table Inheritance

[lordofthelake]

We had some trouble using Tidus in our models that use STI: unless we marked all the deeper descendants to skip_anonymization, the gem would try to create multiple views for the same table, resulting in SQL errors.

This patch would make anonymization run only on direct descendants of ActiveRecord::Base, thus skipping the "deep" models that share the same table. It's not a silver bullet and it would prevent, for example, to have different anonymization strategies for each of the child models, but that wouldn't have worked anyway with the current implementation.

A more thorough solution would require changes about how the SQL is generated (e.g. multiple views for the same table, discriminating on the type column), but this is a quick solution to prevent at least the tasks from failing without manual intervention on all the models.

[tobischo]

Nice idea, I'll have a closer look later :) I am wondering whether it would make sense to just make sure that the view_name is unique. Although in that case it would be necessary to define a 'master' in case no different view name is defined

[lordofthelake]

I had thought about handling it that way, but I didn't want to have strange behaviours about either:

• Changing views depending on the order in which the classes are returned by #descendants (there are guarantees about that)
• Multiple views with different names that anonymize the same table (potentially in different ways or duplicating data).

[tobischo]

Makes sense. The only use case I can think of where this would be problematic would be that you have two pretty similar tables and you are using inheritance to avoid having to rewrite a lot of the stuff. Although that can be solved by using a module.