Bug #5393

Confusing (if not incorrect) key generation with unique indices

Details

Request #5393	Confusing (if not incorrect) key generation with unique indices
Submitted	2005-09-14 04:08 UTC
From	mhart at baselinesolutions dot com dot au
Assigned	alan_k
Status	Closed
Package	DB_DataObject
PHP Version	Irrelevant
OS	Irrelevant
Roadmaps	(Not assigned)

Comments

[2005-09-14 04:08 UTC] mhart at baselinesolutions dot com dot au

Description:
------------
I have a MySQL table with a primary key and two unique indices and I am using the DB_DataObject_Generator class (v1.7.15) to generate the database.ini file.

If the primary key field ('id') is marked as 'auto_increment', then it is the only field in the table__keys section as expected ('id = N'). However, when I remove the 'auto_increment', the two unique fields ('username' and 'email') are also included in this section and they are all marked as '<field> = K'.

Looking through the generator code (specifically the _generateDefinitionsTable method) I can see that the '$keys_out_secondary' array includes any index that is not 'auto_increment', but matches 'primary' OR 'unique' and this seems incorrect to me.

Surely primary keys should be treated differently in a table than unique indices? It's possible that some people may use 'unique' fields as primary keys (although I can't figure out why) - but if you've clearly got primary key fields in the table, then I believe the generator should use them and only them.

Unfortunately the documentation is a little ambiguous as to what one should expect from the DataObject->keys method - the comments in the code indicate that it will return primary keys, but the manual seems more general in its description ("it returns the keys used by the object"). If the intention of the method is to return ALL keys in an object, then it should be returning all keys regardless of if they're auto_increment or foreign or whatever, which it doesn't currently do - however, I believe the usefulness of the method is supposed to be in just returning primary keys (other packages rely on this behaviour too, FormBuilder being the one that I know of).

Now of course I can define the "keys" method for my DO class specifically, but it seems to me that the generator would be quite capable of doing it if it just included the primary keys (instead of the unique indices as well). Perhaps if there are no primary keys in the table, then the unique indices can be used, but this still doesn't quite seem right to me - if there are no primary keys defined, then I don't know why any should be generated.

Is there something that I'm missing here? Maybe there's a use case that I just can't think of, but of course from my position the expected behaviour is just the behaviour that I want :-)

Test script:
---------------
I figured a test script wouldn't be necessary given the description above - if you require one, let me know.