Limitation in Gdn_Model - Cannot handle composite Primary Keys

businessdad

I spotted this issue today, while I was testing an Alpha version of the Badges plugin. One of my tables has a composite primary key (a surrogate key would be superfluous) and, although Gdn_Schema::PrimaryKey() returns, correctly, an array with two field names, class Gdn_Model only takes the first one as the Primary key.

The above happens in file class.model.php, line 172:

     $this->PrimaryKey = $this->Schema->PrimaryKey($this->Name, $this->Database);
     // At this point, the primary key is an array with two fields
     if (is_array($this->PrimaryKey)) {
        //print_r($this->PrimaryKey);
        $this->PrimaryKey = $this->PrimaryKey[0]; // This discards all fields, except the first
     }

I'm not sure of why the Model was implemented in such way, but the result is that it's not working correctly with composite primary keys.

hbf

an interesting (strange to me, not knowing why it was done) design decision. but obviously quite intentional.

x00

Schema is public though.

x00

If you have an issue with validation, this is not a problem to result. You can just add a rule or a result, you can also process the insertion error.

businessdad

@x00 said:
If you have an issue with validation, this is not a problem to result. You can just add a rule or a result, you can also process the insertion error.

I'm not sure I understand this. However, I don't have any issue, I just found myself wondering how composite Primary Keys were handled by Gdn_Model, and I found out that they aren't. As @hbf stated, it's clearly intentional, but it's incorrect. If a PK contains fields, taking the first one is as wrong as taking two of them, or none. Unless there is a specific case for which this approach was designed, I consider it a limitation.

There are many ways to work around it, I simply thought it was worth informing the community, should anyone stumble upon unexpected results.

x00

sure, why not report on git hub?