Why is foreign object's key always accessible as *_id?
I understand your concerns. When the foreign key's field name is equal to it's db_column, I suppose it would be fine to fall back to just appending "_id" -- otherwise the db_column could be used. It's important to have this ID descriptor, as it provides a way to access the foreign key data without forcing resolution of the foreign key.

Would you consider the best fix, then, to use the db_column for the foreign key's ID descriptor except when it is the same as the field name (in which case append "_id")?
 Yes, I just didn't think of the case without any postfix in column name. In my DB, there is always a postfix, it's just different: `_id` or `_guid`.

So yes, «use `db_column` if provided and differs from name, else use `name+"_id"`» seems to be the correct way to fix it, as far as I understand it all.
 +1

In the ForeignKeyField source code, I see this:

``` python
obj_id_name = name + '_id'
...
setattr(model_class, obj_id_name, self._get_id_descriptor())
```

This means that no matter what field is foreign key in, the ID of the object is always accessible as user_id, parent_id, etc. Even if the real column name, the `db_column`, is not *_id at all.

I noticed this because I made a `ForeignUuidField` for my projects. It is based on the standard `ForeignKeyField` but instead of integer `*_id` uses field `*_guid`. But, surprisingly, Peewee still creates field `*_id` with the GUID that I need to load foreign object.

I think the `obj_id_name` from the code above should be equal to `db_column`, at least for this particular situation. (And I think that there is no other possible situations to hardcode it that way, except for default behaviour when `db_column` is not defined by user.)
