Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.11.5

Request #3070 Modify update() to allow primary key changes
Submitted: 2004-12-30 23:45 UTC
From: ate2 at cornell dot edu Assigned:
Status: Wont fix Package: DB_DataObject
PHP Version: Irrelevant OS: Irrelevant
Roadmaps: (Not assigned)    
Subscription  


 [2004-12-30 23:45 UTC] ate2 at cornell dot edu
Description: ------------ Currently update() does not support changing PK values, something that is often useful when using multi-column primary keys or unique constraints on other fields. One manner of implementing this that seems compatible with current structure of update is to load values to the left of WHERE from the dataobject in which update() is invoked while loading the WHERE clause values from $dataObject argument on the right (if provided, otherwise use the values from the left). The example code requires the following specified db configuration. TABLE patch ( resource_id INT, when_made DATETIME, is_locked BIT, content TEXT, PRIMARY KEY (resource_id,when_made,is_locked), FOREIGN KEY resource_id REFERENCES resource(id) ) INSERT INTO patch VALUES 1,'2004-12-31',1,'content'; Reproduce code: --------------- $original = Patch::staticGet(1); $modified =& clone($original); $modified->content = "different"; $modified->is_locked = 0; $modified->update($original); Expected result: ---------------- UPDATE patch SET content='different', is_locked=0 WHERE resource_id=1, when_made='2004-12-31',is_locked=1 Actual result: -------------- UPDATE patch SET content='different' WHERE resource_id=1, when_made='2004-12-31',is_locked=1

Comments

 [2004-12-31 02:30 UTC] alan_k
currently it uses primary keys's to guess what are autoincrement columns. - in hindsight that was perhaps not a great idea.. However, the damage is done and changing that may break alot of existing code. DBDO just dies if it cannot find the autoincrement/nextval col, and you have not manually specified it. I guess if DataObjects2 ever see's the life of day, it will probably have the same behaviour. For the time being define a method keys(), and return only the keys you want to, or use the query() method.