PEAR is archived and read-only

This mirror preserves historical PEAR package releases and metadata so existing references remain available.

Home » Database » DB_DataObject » Bug #3295

docs need to explain how to update with multiple keys

Details

Request #3295docs need to explain how to update with multiple keys
Submitted2005-01-25 22:43 UTC
Fromf dot janssen at mayaxatl dot org
StatusSuspended
PackageDB_DataObject
PHP Version5.0.3
OSany
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.