@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

Reply via email to