Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Serious bug: Primary-key column configured as readonly are auto-incremented upon UPDATE #263

Closed
saurabhnanda opened this issue Jan 6, 2017 · 7 comments

Comments

@saurabhnanda
Copy link
Contributor

Given this core function - please notice ctKey=()

    updateExisting :: HasDb m => LocalTime -> ClientTagRead -> m [ClientTagRead]
    updateExisting now existingCt = updateRow clientTagTable
      (
        \ctR -> ClientTag
                {
                  ctKey = ()
                , ctCreatedAt = ()
                , ctUpdatedAt = (pgLocalTime now)
                , ctClientId = ctR ^. clientId
                , ctTags = constant $ nub $ (existingCt ^. tags) ++ [newTag ^. tag]
                }
      )
      (\ctR -> (ctR ^. clientId) .== (pgInt8 $ newTag ^. clientId))

... and the supporting types:

type ClientTagRead = ClientTag
  Int64 -- key
  LocalTime --createdAt
  LocalTime --updatedAt
  Int64 -- client Id
  [Tag] -- tags

type ClientTagWrite = ClientTag
  () -- key
  () --createdAt
  LocalTime --updatedAt
  Int64 -- client Id
  [Tag] -- tags

Here's the behaviour I'm seeing -- if the id of the row being updated is 5, after the update it changes to 6 in the DB! I presume this is because the generated SQL has id=DEFAULT or suchlike. And the DEFAULT for the id column is nextval('client_tags_id_seq'::regclass)

@xldenis
Copy link
Contributor

xldenis commented Jan 6, 2017

Have you tried changing your definition to make your column optional (so that instead of () you use Nothing) ?

@bergmark
Copy link
Contributor

bergmark commented Jan 6, 2017

This is a consequence of #92

@saurabhnanda
Copy link
Contributor Author

@xldenis @bergmark I tried using (Maybe (Column x)) and using Nothing instead of () as the value. Same buggy behaviour. Only when I specify Just $ row ^. key does it preserve the value.

Very, very bad bug.

@tomjaguarpaw
Copy link
Owner

Please calm down. readOnly isn't even supported in Opaleye. It was a suggestion I made to @sras on another issue. He claimed it worked and closed the issue. If it doesn't work then feel free to reopen the issue, or even better, fix it.

@saurabhnanda
Copy link
Contributor Author

saurabhnanda commented Jan 27, 2017

So, due to #92 we are forced to provide values for every single field in UPDATE calls. If in the PGWrite version of the record a field is mapped to Maybe (Column x) and the value for this field is a Nothing, the queryRunner maps it to DEFAULT, right? Which forces us to have Just $ pgR ^. existingKey as values for fields that we don't want to change.

What was the situation before #92 @bergmark ?

PS: Does this also mean that it's not really a readonly column issue? Nothing mapping to DEFAULT is the problem here?

@tomjaguarpaw
Copy link
Owner

tomjaguarpaw commented Feb 25, 2017

Which forces us to have Just $ pgR ^. existingKey as values for fields that we don't want to change.

Correct, with runUpdate you have to wrap all optional fields that you don't want to change in Just. Here is an approach that makes life easier: bf625fb

Does this also mean that it's not really a readonly column issue?

It is a readonly column issue. readonly doesn't do what I expected it to do, sorry. I suggest not to use readonly.

@tomjaguarpaw
Copy link
Owner

I'm closing this because readonly is not a supported part of Opaleye. All related discussion can continue on #92.

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

No branches or pull requests

4 participants