Home » Database » DB_DataObject » Bug #3295
docs need to explain how to update with multiple keys
Details
| Request #3295 | docs need to explain how to update with multiple keys |
|---|---|
| Submitted | 2005-01-25 22:43 UTC |
| From | f dot janssen at mayaxatl dot org |
| Status | Suspended |
| Package | DB_DataObject |
| PHP Version | 5.0.3 |
| OS | any |
| Roadmaps | (Not assigned) |
Comments
[2005-01-25 22:43 UTC] f dot janssen at mayaxatl dot org
Description:
------------
php 5.0.3, pear 1.3.4, DB 1.6.5, DB_DataObjects 1.7.2, postgresql 7.3.8
(db-object files generated with php 5.0.2)
A simple update on a db-object gives an error:
DB_Fleet: ERROR: update: No Data specifed for query ,
Reproduce code:
---------------
http://spacewar.mayaxatl.org/test.phps
http://spacewar.mayaxatl.org/db/Fleet.phps
http://spacewar.mayaxatl.org/db/schema/spacewar.ini
Expected result:
----------------
An update-query should be sent to the database. Original name is not equal to the new name.
Actual result:
--------------
The query is not generated at all. Only ", " instead of
"UPDATE fleet SET name='test' WHERE owned_by=25"
Debug output:
DB_Fleet: CONNECT: NEW CONNECTION
DB_Fleet: CONNECT: pgsql://spacewar:***@localhost/spacewar a5b8d572066c9ef64e7ba6968c9a07ed
DB_Fleet: CONNECT: a:1:{s:32:"a5b8d572066c9ef64e7ba6968c9a07ed";O:8:"DB_pgsql":26:{s:10:"connection";i:0;s:7:"phptype";s:5:"pgsql";s:8:"dbsyntax";s:5:"pgsql";s:14:"prepare_tokens";a:0:{}s:13:"prepare_types";a:0:{}s:19:"transaction_opcount";i:0;s:3:"dsn";a:9:{s:7:"phptype";s:5:"pgsql";s:8:"dbsyntax";s:5:"pgsql";s:8:"username";s:8:"spacewar";s:8:"password";s:5:"sw998";s:8:"protocol";s:3:"tcp";s:8:"hostspec";s:9:"localhost";s:4:"port";b:0;s:6:"socket";b:0;s:8:"database";s:8:"spacewar";}s:3:"row";a:0:{}s:8:"num_rows";a:0:{}s:8:"affected";i:0;s:10:"autocommit";b:1;s:9:"fetchmode";i:1;s:8:"features";a:4:{s:7:"prepare";b:0;s:8:"pconnect";b:1;s:12:"transactions";b:1;s:5:"limit";s:5:"alter";}s:13:"errorcode_map";a:0:{}s:16:"prepared_queries";N;s:15:"prepare_maxstmt";i:0;s:10:"last_query";s:0:"";s:22:"fetchmode_object_class";s:8:"stdClass";s:7:"options";a:7:{s:10:"persistent";b:0;s:3:"ssl";b:0;s:5:"debug";i:0;s:14:"seqname_format";s:6:"%s_seq";s:8:"autofree";b:0;s:11:"portability";i:0;s:8:"optimize";s:11:"performance";}s:3:"dbh";N;s:6:"_debug";b:0;s:19:"_default_error_mode";N;s:22:"_default_error_options";N;s:22:"_default_error_handler";s:0:"";s:12:"_error_class";s:8:"DB_Error";s:16:"_expected_errors";a:0:{}}}
DB_Fleet: CONNECT: USING CACHED CONNECTION
DB_Fleet: CONNECT: USING CACHED CONNECTION
DB_Fleet: 3: got keys as a:2:{i:0;s:8:"owned_by";i:1;s:4:"name";}
DB_Fleet: CONNECT: USING CACHED CONNECTION
DB_Fleet: ERROR: update: No Data specifed for query ,
FALSE
[2005-01-25 23:00 UTC] f dot janssen at mayaxatl dot org
What's this piece of code for?? Doesn't seem logical to stop when the current key indeed is a key.. It would always stop..
// beta testing.. - dont write keys to left.!!!
if (in_array($k,$keys)) {
continue;
}
I've changed it to !in_array and I get a query, but
still not the right one:
UPDATE fleet SET name = 'test' WHERE fleet.name = 'test'
should be
UPDATE fleet SET name='test' WHERE fleet.owned_by=25
[2005-01-25 23:27 UTC] f dot janssen at mayaxatl dot org
I've situated the problem. The table I use has the following sturcture:
CREATE TABLE fleet (
owned_by integer primary key,
name varchar(255) unique
)
Both columns are keys, so they both turn up in the where clause of the update query.
How to solve?
* Make update detect a situation like this
* Be sure to leave one key intact, while updating the other one(s) and give a decent error otherwise
OR
* before updating, remember the original values of the key-fields.
[2005-01-26 08:53 UTC] f dot janssen at mayaxatl dot org
The links work fine for me..
Setting sequenceKey does not work, since update does not use that method.
The problem is that key columns cannot be updated. And because all my columns have a key, I cannot update anything at all. I read bug #3070 and realise this is a special case of that problem. I advise you to document the fact that key columns cannot be updated and include the possible workarounds.