Hi Erich, Yes, we do. Node_Package_Status should be updated according to the changes of the "Packages" table. If Node_Package_Status has the records referring to the primary key whose record does not exist in the "Packages" table, this is a big hole of data integrity in database. We can not manage this kind of wrong data integrity manually and it is really ugly to handle it by ourselves.
If the records of Node_Package_Status need to be kept regardless of the changes of Packages, we have to remove the cascaded deletions feature from "Node_Package_Status". Of course, since we have used the "cascade deletions" feature in INNO-DB, we should be very careful of updating the records of the Packages table because many other tables are referring to it and their entries will be affected by its changes automatically whether its changes are intended or not. Again, the INNO-DB feature in Node_Package_Status is not what we need, we have to remove it and we should manually manage the foreign keys in it. Regards, - DongInn Erich Focht wrote: > Hello DongInn, > > I have a question about cascaded deletions in INNODB: > > Suppose we have: > - in table Packages a record: > (id=1, package=apitest, version=1.0, ...) > > - in Node_Package_Status a linked record: (old style, to avoid rants ;-) > (node_id=10, package_id=1, current,error,requested,curr,status,ex_status, > selected,errorMsg,client_nodes) > [listed all fields, which are mostly unused. I think less but with clear > meaning would be nicer] > > Packages.id and Node_Package_Status.package_id are linked through INNO-DB. > Does the ON DELETION CASCADE mean that when I delete the record with id=1 > in Packages the corresponding record (package_id=1) in the > Node_Package_Status table? > > Do we want that? > > IMO this would be wrong behavior, as it means that if for some reason the > record in Packages is deleted (for example when adding a record with new > version), we lose the valid record in Node_Package_Status and nobody can > tell that the apitest package was selected/installed on that particular node. > > Thanks, > best regards, > Erich > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Oscar-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oscar-devel ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Oscar-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oscar-devel
