Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is it possible to add the ability to use "ON DELETE RESTRICT" or "ON UPDATE RESTRICT"? #569

Closed
scpeterson opened this issue Jan 12, 2015 · 7 comments

Comments

@scpeterson
Copy link

Currently, using System.Data.Rule limits us to so that we can't use RESTRICT via the API. I am using Execute.Sql to get this, but is there a way to have it in the API?

@scpeterson
Copy link
Author

Would it be possible to inherit the Rule and add more options, like RESRICT?

@tommarien
Copy link
Contributor

@scpeterson Wouldn't the ON DELETE RESTRICT act just the same as Cascade.NoAction ?

@scpeterson
Copy link
Author

It depends on the database. In some, NO ACTION is a deferred check. In others they are the same. In MySQL for example, foreign key constraints are checked immediately, so NO ACTION is the same as RESTRICT. My understanding however, is that according to standards, NO ACTION is deferred and RESTRICT acts immediately. It would be nice to have in in FluentMigrator so developers can decide for themselves which to use.

@tommarien
Copy link
Contributor

@scpeterson Maybe PostgreSQL is such a DBMS ? although the documentation is not that clear on the difference between NO ACTION and RESTRICTED (deferrable or not). What would be the outcome difference of an operation in either NO ACTION or RESTRICTED ?

@scpeterson
Copy link
Author

@tommarien I'm not completely sure although I could look into it. My initial reason for the comment was that I was trying to duplicate what we have using Fluent Migrator, and found that Data.Rule limited things. My feeling is that if there is any difference between databases, then we need to make sure NO ACTION and RESTRICT can be defined separately.

@tommarien
Copy link
Contributor

@scpeterson agreed, but we need to justify the reason of existance of this specific Rule implementation.

@tommarien
Copy link
Contributor

@scpeterson Atm i consider this closed, as there seems to be no practical justification for this to change. If you still feel this is necessary, please give a practical use case

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants