@gravitystorm commented on this pull request.
> @@ -39,6 +49,10 @@ class Note < ApplicationRecord
DEFAULT_FRESHLY_CLOSED_LIMIT = 7.days
+ def comments_with_extra_open_comment
> I am not sure what you mean with that. The idea of
> `Note#comments_with_extra_open_comment` is to hide the logic inside the model
> and make it obvious to developers that this method returns something special.
>
> I've now added a `Note#api_comments`-method which should always return the
> full list of note comments including the `open`-comment
But the point I'm making is that this still leaks complexity out of the Note
model. We should have:
* Note#author
* Note#body
* Note#comments
That's all that both the web view and the API need. The web view can use them
directly. The API can use the first two to make the legacy-first-comment.
I can see that the web view has some things like `if @note.body_migrated?` but
the view should not care about this.
Now your point about the collection proxy object is a good one, and one I need
to think about. Perhaps we can do something like (completely untested):
```
def comments
if body_migrated?
raw_comments
else
raw_comments.offset(1)
end
end
```
... to get a collection proxy either way.
Partly this depends on the data migration strategy - whether we expect to do
one of the two following options:
* A migration that, for each note (and in a transaction) creates the body,
author, and deletes the first comment
* Two migrations, the first that backfills the body and author, and the second
that deletes all the first comments. But that's extremely risky (imho) since
the second migration is must-work-first-time.
Final point - there's still references to "opened comment" in the PR, but it's
the "first comment" that we're focussing on.
--
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/pull/4481#discussion_r1784897557
You are receiving this because you are subscribed to this thread.
Message ID:
<openstreetmap/openstreetmap-website/pull/4481/review/2343525...@github.com>
_______________________________________________
rails-dev mailing list
rails-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/rails-dev