Integer primary keys should be able to be pre-specified upon object creation

[mpontillo]

Description

I'm writing some Buffalo-based proof-of-concept code that successfully used a string as a primary key for my model object. When I learned that our database is much faster when indexing integers rather than strings, I decided to try switching to an int64 type.

In order to ensure uniqueness, the model object generates the ID based on an 8-byte hash of the object's other fields. Therefore, I am not using an auto-incrementing ID, and the id field should be included when creating the record.

All this works fine when the primary key is a string, since Buffalo does not attempt to prevent it from being passed to the database, or generate one (like it does with a UUID).

When using the int64 type, however, the code in genericCreate() specifically removes the ID field:

		cols.Remove(model.IDField())

Expected Behavior

Non-zero primary keys should not be removed in genericCreate().

Actual Behavior

The key I passed into the model object was removed from the record before being passed to the database, eventually resulting in an error as follows:

mysql create: Error 1364: Field 'id' doesn't have a default value

Info

-> Buffalo (CLI): Checking minimum version requirements
✓ Your version of Buffalo (CLI), v0.16.20, meets the minimum requirements.

I don't think the long form of buffalo info is useful for this bug report, but please let me know if you would like any additional information.

[mpontillo]

It occurs to me that I'm not sure if auto-incrementing primary keys start at zero or one. If they start at zero, this would need to be implemented by allowing the ID to be a null value, in order to indicate the lack of a primary key.

[sio4]

Duplicate: #586 and I think it is considerable.