Properly Handle Primary Key Alternatives
Created by: xivSolutions
Issue revealed via @stephensong in issue #68 (closed)
Massive currently presumes:
A. All PK's are generated B. All PK's are serial ints (@dmfay 's PR #74 partially addresses this for UUID Pk's)
We need to handle:
int pks (generated or not) uuid pks (generated or not) string pks (generated or not)
In all cases the type is less important than handling the generated/not-generated cases.
The .save()
method will currently not correctly handle cases where the PK is not assumed to be generated.
@robconery When caling save()
and passing an object which includes the PK field(s!) because the pk is not generated, Massive will skip insert
and go right to update
. We CAN detect when a PK is generated or not (I have this working fine, as part of table load). However, when the PK is not-generated, we need to:
A. Employ the new "upsert" functionality introduced in Postgres 5, or;
B. throw, and insist that the caller explicitly specify either insert
or update
C. Some other option I haven't thought of yet...
If we go the "upsert" route, save
will break for those with older Postgres installations. It is, though, the more elegant way to handle the situation. We could also check for Postgres version, and degrade if necessary into a crude manual handling of a failed insert
due to key violation, then proceed to update
, but that's kinda ugly.
Thoughts?