Skip to content

Conversation

@PeterJCLaw
Copy link
Contributor

This fixes #48 and ensures that objects which specify an explicit primary key value will have that value returned from 'insert'.

This makes insert reliably usable for models which don't have an id field (which previously AttributeErrored or returned None, depending on whether a conflict was anticipated).

Note: this is potentially quietly breaking for models which:

  • specified a non-id primary key, and
  • also had a separate id field

This scenario seems sufficiently unlikely to be worth the fix.

This fixes SectorLabs#48 and ensures that objects which specify an explicit
primary key value will have that value returned from 'insert'.

This makes `insert` reliably usable for models which don't have
an `id` field (which previously `AttributeError`ed or returned
`None`, depending on whether a conflict was anticipated).

Note: this is potentially quietly breaking for models which:
- specified a non-`id` primary key, and
- also had a separate `id` field
This scenario seems sufficiently unlikely to be worth the fix.
@Photonios
Copy link
Contributor

Many thanks and my apologies for the delay!

@Photonios Photonios merged commit f4ce6ad into SectorLabs:master Jun 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

PostgresQuerySet.insert assumes the existence of an 'id' field

2 participants