646 self.doexecmany(cnx, statement, attrs) |
646 self.doexecmany(cnx, statement, attrs) |
647 |
647 |
648 def delete_relation(self, cnx, subject, rtype, object): |
648 def delete_relation(self, cnx, subject, rtype, object): |
649 """delete a relation from the source""" |
649 """delete a relation from the source""" |
650 rschema = self.schema.rschema(rtype) |
650 rschema = self.schema.rschema(rtype) |
|
651 # we should not issue UPDATE on inlined relations when subject is going |
|
652 # to be deleted. |
|
653 # Unless object is also going to be deleted and is not equal to the |
|
654 # subject, in this case DELETE should occur in a order which cubicweb |
|
655 # doesn't handle (yet). For example |
|
656 # cubicweb/server/test/unittest_migractions.py::MigrationCommandsTC::test_add_drop_entity_type |
|
657 # trigger such case. |
|
658 if ( |
|
659 rschema.inlined and cnx.deleted_in_transaction(subject) |
|
660 and (subject == object or not cnx.deleted_in_transaction(object)) |
|
661 ): |
|
662 return |
651 self._delete_relation(cnx, subject, rtype, object, rschema.inlined) |
663 self._delete_relation(cnx, subject, rtype, object, rschema.inlined) |
652 if cnx.ertype_supports_undo(rtype): |
664 if cnx.ertype_supports_undo(rtype): |
653 self._record_tx_action(cnx, 'tx_relation_actions', u'R', |
665 self._record_tx_action(cnx, 'tx_relation_actions', u'R', |
654 eid_from=subject, rtype=rtype, eid_to=object) |
666 eid_from=subject, rtype=rtype, eid_to=object) |
655 |
667 |