Re: DB_DataObject, UNIQUE-keys and update-method

Alan Knowles wrote:

Can you file it as a bug, with suggestions on how it may work. Ok. I file it.

In short I don't see any reason for DO to react for UNIQUE-constraints at all. If they are constantly needed as keys they should be declared as (primary) keys. I think they are DB-engines concern. Does anyone else have opinion on this? I'll file the bug in a couple of days. --- J-P Arvo

Justin Patrin wrote:

On Thu, 08 Jul 2004 16:40:18 +0300, Jari-Pekka Arvo <ippo@netti.fi> wrote:

Hi, I noticed that DB_DataObjects update()-method can't be used to update columns that are part of a key declared as UNIQUE. In my case I wanted to update a table which have a primary key and a unique-key consisting of tree columns. What happened was that nothing got updated, no error raised and when I checked debug output I found out that the method uses UNIQUE-constraints in WHERE-clause and didn't even try to update the fields I wanted. I know I can use $do->query() -method (did it already) and I know I can manually edit the 'foo.ini'-file (not recommended) but I think this is a design flaw in DB_DataObject-package. UNIQUE -keys are a good way to make sure the data in a single relation keeps its coherency, they are not (usually) used to referring table in joins. What if someone makes a typo when inserting data in a field that just happens to be a part of a unique key? Should the mistake be irreparable (as in my opinion this design conception suggests)? To put it shortly: I think that primary keys and unique-keys differ in semantics so much, that they should be treated separately in DO-code. Why not just left them out of any key-definitions (in PHP-code)?

I agree and this has been brought up before, although usually about primary keys. If DO is blocking all UNIQUE constraints, then this should definately be fixed. The major problem here is that DO doesn't know the difference between a primary key, a key, and a unique constraint. (I'm not a DB_DataObject developer, but...) Could you possibly look at the code and try to figure out a way to handle this? You could perhaps make a primaryKey() method in the DO when, if it exists, would be used exclusively in the WHERE clause for updates, leaving the other keys out to be updated as you please. I wouldn't think this would that hard of a change to the code. Alan, have you made any changes to this in CVS? Do you have a solution cooking, or should we provide a patch?