jimandClaude Opus 5
e1d2eb48c2
Seven UPDATE statements wrote DateModified unconditionally, so re-crawling or re-ingesting identical content marked Blogs, Posts and Notes rows as modified. Each now carries a WHERE guard covering every column in its SET list, so SQLite matches zero rows on a no-op. Guarded: AddPost's insert-failure fallback and blog stamp, AddNote's blog stamp, UpdateBlogLikesNewestTimestamp, UpdateNoteReplyText, UpsertPostFromTextFile, SetBlogTTFolderPath, UpdatePostContentFields. Also: - Blogs.DateAdded is no longer rewritten when a new post arrives for a known blog. A new post is not a new blog, and rewriting the column both destroyed the registration date and made every insert look like a change. - Posts.NotesGatheredDateTime is crawl bookkeeping that moves on every pass, so it no longer moves DateModified on its own. It is still written each pass, but the timestamp is wrapped in a CASE on the pre-UPDATE HasNotesGathered value so only the flag flipping counts. These statements now return 0 rows for "found but unchanged" as well as "not found"; CorrectMode's postsUpdated tally consequently counts rows actually changed, matching what its dry-run diff reports. Co-Authored-By: Claude Opus 5 <[email protected]>