Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While digging deeper into this gem, I stumbled on the failing tests.
The root cause has nearly always been the missing
user_id
for a blog post, which is required to be existent since thebelongs_to :user
defined in thepost
model is not marked asoptional: true
(a change introduced with Rails 5 after a quick investigation).It's not an issue for
category_id
, as this is included in the factory and covers the presence in most cases (with exception of the system tests).From my point of view there are two options how this can be treated in general and I'm happy to put this here for discussion (with partially prepared changes).
1. Mark the user and category as optional
The provided atom view checks for the presence of a user and includes the user's name if one has been set. So it seems to be a valid use case and I agree that it makes sense under some circumstances to leave the user unset in some cases.
2. Let the user and category be mandatory
On the other hand it's rather usual (from my perspective) that a blog post has an author assigned in order to show related articles from this author. The same holds for categories, e.g. for better filtering. I think most writers / bloggers want their content to be found and seen.
What has been done so far
To make the specs work for me, I went the second route. At least in terms of adjusting the specs. Based on that a
spina_user
factory has been introduced (shamelessly stolen from thespina
gem 👮♂️) and used for thespina_blog_post
. Also the system test for creating apost
has been adapted to the UI.To emphasise the second route, it is thinkable to make the model specs a little bit more expressive.
Also adding
NOT NULL
constraints on the database level could be an option here:user_id
,category_id
, maybe also fortitle
andcontent
as they have a presence validation already in placename
's presence is also validated, a database constraint should not hurtI was thinking about if this could be a breaking change, but as at least Spina 2.1.0 (which requires at least Rails 6.1) is required for this gem, there does not seem to be any peril here and most likely all users have been confronted with the requirements of choosing an user and a category for a blog post.
Which leaves still the option that someone has overwritten / extended the models themselves and mitigated the need to fill in these fields...🙈
I'm looking forward to hear your thoughts / insights and happy to discuss this topic. 🙂