Destroy default content view on cascade when deleting environment

[iNecas]

Also save the default content_view explicitly. Here is what happened without
this changes:

1. Create environment (default content view and content_view_version was
   crated)
2. Delete the environment (content_view stayed there because
   :dependent=> :destroy was missing)
3. When creating an environment with the
   same name, the content_view was not created, because another content view with
   the same name already existed. However, because the content_view was being
   saved as part of saving content_view_version, the exception was not thrown
   (and the content_view_version was saved successfully without association to
   any content_view)
4. When promoting some time after this incident (that
   happened unnoticed), "nil pointer exception" occurred while promoting, because
   the default content view was not there.

[bbuckingham]

ACK

[pitr-ch]

ACK

[lzap]

ACK

[dmitri-d]

NACK. You don't need to call save! (or update_attributes!, or create!) to validate the object. Call #valid? instead. Also, could you add a test for this?

[iNecas]

NACKNACK :) valid? returns boolean, I want the exception, since that's how other validations work as well in current status of orchestration.

[iNecas]

I can add some test thou

[dmitri-d]

NACKNACKNACK: raise RecordInvalid.new(content_view_instance) unless content_view_instance.valid?

[iNecas]

@witlessbird Could you please be more specific about the advantages of this solution (and in the future, stating that reasons directly in the first NACK comment, it saves some time:)? Implicit saving of associated records just proved to be unreliable: calling content_view_version.save! saved without problems even when the content_view was invalid. I can imagine situation where the content_view could be valid when checking, but something might cause the actual save wont be successful and we wouldn't even notice.

[dmitri-d]

@iNecas The triple NACK was made in jest. On the serious side, the behaviour you are describing is very strange: according to the docs and the code, validations should be run on the children when save! is called on the parent. Your approach is fine as a work-around, but I think we should find the root cause of the issue. Did you look into why this is happening?

[iNecas]

Tests added

[dmitri-d]

ACK.

[iNecas]

@witlessbird found the real cause https://github.com/iNecas/rails-fail/pull/1, I will retest it with this approach

[iNecas]

I've added :validate => true to the default_content_view association so that the validation happens when calling content_view_version.save!. We need to check other associations to make sure similar things doesn't happen somewhere else. This is, however, out of the scope of this PR. We need also handle the validation errors from associations to give a user more descriptive message. Now it would say 'Environments are invalid'.