bojanb wrote: > > I have columns in my database that logically shouldn't be null. > However, I allow them to be null while the user is editing (creating) > objects interactively. As this is done in a transaction, and values > are checked before a commit, it's assured that nobody else ever sees > invalid values and the integrity of the data is preserved. > > This would be an ideal use case for deferred constraints; > unfortunately, Postgres doesn't support deferred CHECK constraints so > the validation is done in code. This in turn means that the fields are > not declared as "nullable=False". > > This leads to a problem when referential integrity needs to be > preserved. When a referred object is deleted, SQLA's default behavior > is to set child's object foreign key field to None (e.g. see > http://groups.google.com/group/sqlalchemy/browse_thread/thread/1f9990e3a9a2a869). > This in turn lets the RDBMS delete the referred object, instead of > throwing referential integrity exception. I am left with hanging child > objects even though I specified ondelete='RESTRICT' for the relation. > > Is there any way around this? I've tried passive_deletes='all' but it > didn't do the trick...
why not just add a @validates method to your class, set for the foreign key attribute, which ensures that the incoming value is not "None" ? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
