Users changing publication dates for existing posts causes a constraint violation.

[zenhack]

I haven't dug into this yet, but @shaunagm's posts aren't being pulled into correctly this is showing up, and this is showing up in the logs:

INFO:root:Syncing posts for blog u'This Blog, Like Everything Else In The Universe, Is Temporary' by u'shauna'
INFO:root:Added new post u'http://notes.shaunagm.net/post/138863725522'
INFO:root:Added new post u'http://notes.shaunagm.net/post/138624497752'
INFO:root:Added new post u'http://notes.shaunagm.net/post/137973439322'
Traceback (most recent call last):
  File "/var/lib/openshift/54b1c1554382ecb4ee0001bd/python/virtenv/bin/ironblogger", line 11, in <module>
    execfile(__file__)
  File "/var/lib/openshift/54b1c1554382ecb4ee0001bd/app-root/runtime/repo/scripts/ironblogger", line 21, in <module>
    main()
  File "/var/lib/openshift/54b1c1554382ecb4ee0001bd/app-root/runtime/repo/ironblogger/cli.py", line 73, in main
    args.func(args)
  File "/var/lib/openshift/54b1c1554382ecb4ee0001bd/app-root/runtime/repo/ironblogger/cli.py", line 60, in wrapper_fn
    commands[cmd]['fn']()
  File "/var/lib/openshift/54b1c1554382ecb4ee0001bd/app-root/runtime/repo/ironblogger/tasks.py", line 166, in sync_posts
    blog.sync_posts()
  File "/var/lib/openshift/54b1c1554382ecb4ee0001bd/app-root/runtime/repo/ironblogger/model.py", line 167, in sync_posts
    db.session.commit()
  File "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/sqlalchemy/orm/scoping.py", line 114, in do
    return getattr(self.registry(), name)(*args, **kwargs)
  File "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/sqlalchemy/orm/session.py", line 703, in commit
    self.transaction.commit()
  File "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/sqlalchemy/orm/session.py", line 361, in commit
    self._prepare_impl()
  File "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/sqlalchemy/orm/session.py", line 340, in _prepare_impl
    self.session.flush()
  File "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/sqlalchemy/orm/session.py", line 1718, in flush
    self._flush(objects)
  File "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/sqlalchemy/orm/session.py", line 1789, in _flush
    flush_context.execute()
  File "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/sqlalchemy/orm/unitofwork.py", line 331, in execute
    rec.execute(self)
  File "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/sqlalchemy/orm/unitofwork.py", line 475, in execute
    uow
  File "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/sqlalchemy/orm/persistence.py", line 64, in save_obj
    table, insert)
  File "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/sqlalchemy/orm/persistence.py", line 558, in _emit_insert_statements
    execute(statement, params)
  File "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1449, in execute
    params)
  File "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1584, in _execute_clauseelement
    compiled_sql, distilled_params
  File "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1698, in _execute_context
    context)
  File "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1691, in _execute_context
    context)
  File "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/sqlalchemy/engine/default.py", line 331, in do_execute
    cursor.execute(statement, parameters)
sqlalchemy.exc.IntegrityError: (IntegrityError) duplicate key value violates unique constraint "post_blog_id_page_url_key"
DETAIL:  Key (blog_id, page_url)=(43, http://notes.shaunagm.net/post/137973439322) already exists.
 'INSERT INTO post (blog_id, guid, timestamp, counts_for, title, summary, page_url) VALUES (%(blog_id)s, %(guid)s, %(timestamp)s, %(counts_for)s, %(title)s, %(summary)s, %(page_url)s) RETURNING post.id' {'blog_id': 43, 'title': u'Self and performance', 'timestamp': datetime.datetime(2016, 1, 25, 21, 27, 54), 'summary': u'<p>When David Bowie died two weeks ago, I felt sad, but it was nothing compared to the outpouring of grief and remembrance from friends and from the culture at large.\xa0 I have always liked Bowie\u2019s music, his style, his interviews, the characters he\u2019s played in movies.\xa0 But I never quite got <i>Bowie</i>.<br /></p><p><a href="http://www.willwilkinson.net/flybottle/2016/01/11/why-david-bowie-is-important-to-me/">This tribute piece helped me realize why:</a><br /></p><blockquote><p>The sickness of my generation is a zealous attachment to \u201cauthenticity.\u201d It is stultifying, oppressive, maybe even deadly, and premised on false assumptions about the nature of personal identity. Bowie is the antidote. He taught that persona is per

[shaunagm]

I'm guessing this has something to do with my altering the datestamp so that this particular post counted for the next week, after which I decided I didn't actually care. Presumably the script is supposed to identify the date change and update the timestamp field when that happens, but it looks like for some reason it tried to create a new row. Page_url would be the same for both rows, and perhaps blog_id would as well (not sure how that's generated), hence the unique constraint violation.

[zenhack]

Relevant snippet of code is here:

https://github.com/zenhack/iron-blogger2/blob/master/ironblogger/model.py#L146

You're impression is spot on. I should tweak that code such that it can't cause a constraint violation.

For the immediate term, I'll just delete the original post from the db and let it re-fetch it.

[zenhack]

@shaunagm, I did the manual db tweak I mentioned, and your posts are updating again. I'm leaving this issue open, since user input triggering a constraint violation is unambiguously a bug.

It's not 100% obvious what the right solution is; I think when I wrote the code I was thinking in terms of tweaking the date on an existing post being "cheating", and something that really ought to be run past others. This is probably true, but I don't really think it's worth having that be part of the software's threat model. This is supposed to be a friendly activity, and there are easier ways to game the system anyway.

My inclination is to just remove the first half of that big and clause, so there's no requirement for the publication date at all. Does that sound sensible?

//cc @hlieberman @jywarren
To everyone else, background: Shauna posted slightly before midnight for a post she meant to count for the next week, and so the system didn't give her credit. I offered to let her tweak the feed to adjust the date, and the software choked.
(feel free to @-mention anyone else; I don't know everyone's github username, or whether they have accounts).

[shaunagm]

I am happy to never tweak a date again - it is really just a dollar, after all - but I'm also fine with giving bloggers the benefit of the doubt and not checking to see if they're cheating.

[zenhack]

I think I'm going to change it such that it allows adjusting dates; it seems like the simplest thing to do. I'm changing the title for this issue.