Thread: [SQLObject] Deleting Related Joins
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Alex Le D. <al...@ps...> - 2005-10-10 02:32:58
|
I notice that related joins do not remove the reverse reference when a record is deleted. For example: class Stock (SQLObject) : dbCode = StringCol() dbPart = RelatedJoin('Part') class Part (SQLObject) : dbName = StringCol() dbStock = RelatedJoin('Stock') s = Stock(dbCode='stockone') p = Part(dbName='partone') p.addStock(s) p.destroySelf() This will still leave the record 's' pointing to the id of 'p'. If 's.dbStock' is accessed then you get an exception telling you that the ID referenced does not exist (because p(1) has been deleted). You can get rid of the reverse references by providing a method to handle the removal. Is the best way or have I missed a method call that does the cleanup automatically? For example : class Part (SQLObject) : dbName = StringCol() dbStock = RelatedJoin('Stock') def destroySelf (self) : for stock in self.dbStock : stock.removePart(self) super(Part, self).destroySelf() return cheers, Alex. -- Poseidon Scientific Instruments Pty Ltd 1/95 Queen Victoria St FREMANTLE WA, AUSTRALIA Ph: +61 8 9430 6639 Fx: +61 8 9335 4650 Website: www.psi.com.au PSI, an ISO-9001 Company CONFIDENTIALITY: The contents of this email (and any attachments) are confidential and may contain proprietary and/or copyright material of Poseidon Scientific Instruments Pty Ltd (PSI) or third parties. You may only reproduce or distribute the material if you are expressly authorised to do so. If you are not the intended recipient, any use, disclosure or copying of this email (and any attachments) is unauthorised. If you have received this email in error, please immediately delete it and any copies of it from your system and notify PSI by return email to sender or by telephone on +61 (08) 9430 6639. DISCLAIMER: You may only rely on electronically transmitted documents when: (a) those documents are confirmed by original documents signed by an authorised employee of PSI; and/or (b) the document has been confirmed and checked against a hard copy of that document provided by PSI. VIRUSES: PSI does not represent or warrant that files attached to this e-mail are free from computer viruses or other defects. Any attached files are provided, and may only be used, on the basis that the user assumes all responsibility for any loss or damage resulting directly or indirectly from such use. PSI's liability is limited in any event to either the re-supply of the attached files or the cost of having the attached files re-supplied. |
From: pierrebai <pie...@ho...> - 2005-10-18 14:23:00
|
Which database are you using? There is an undocumented (AFAIK) argument in the column initialization called cascade that allows foreign keys to be handled as either deleted, nulled or prohibit removal. Check the Col.py source code, but this seems to be implemented only for postgresql. I alos read somewhere that related join table didn't get their foerign keys declared as such and thus it still led to a corrupted database. I sure hope this will be fixed (if not already fixed). Any author could comment on this? |
From: Andreas K. <an...@ko...> - 2005-11-18 14:52:22
|
Am Montag, den 17.10.2005, 17:57 +0000 schrieb pierrebai: > Which database are you using? There is an undocumented (AFAIK) argument i= n the > column initialization called cascade that allows foreign keys to be handl= ed as > either deleted, nulled or prohibit removal. Check the Col.py source code,= but > this seems to be implemented only for postgresql. >=20 > I alos read somewhere that related join table didn't get their foerign ke= ys > declared as such and thus it still led to a corrupted database. I sure ho= pe this > will be fixed (if not already fixed). Any author could comment on this? delete on tables that have foreign key relations, especially with cascade delete are seldom a good idea. We just finished a bug at work, where parts of the accounting data was disappearing from the database, because someone deleted some data in a referenced table. In this case it would have been enough to remove the foreign key restraint, but in most cases you want a column to flag logically deleted rows. Considering your example, with cascaded deletes, deleting a part might invalidate for example invoices where item reference these parts. So in 90% of cases SQL DELETE is the wrong thing to do. Andreas >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > sqlobject-discuss mailing list > sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss |