Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[5.x] Avoid querying status #9317

Merged
merged 12 commits into from
Apr 11, 2024
Merged

[5.x] Avoid querying status #9317

merged 12 commits into from
Apr 11, 2024

Conversation

jasonvarga
Copy link
Member

@jasonvarga jasonvarga commented Jan 12, 2024

Closes #2217

The issue

When you have a collection with date behaviors like a typical blog with scheduled posts (past dates are visible, future dates are not) whenever the current time ticks over the scheduled date, the entry would not be displayed.

This is because we were filtering by "status" in order to prevent drafts from being displayed by default.
The future dated entries have a status of "scheduled", and they get stored in the Stache index (or even in the database table if using the Eloquent driver). When the time ticks over the publish date, there's nothing that would update the indexed status, so the entry would continue to be filtered out.

The solution

This PR reworks logic so that we don't ever query status, as it would never automatically update. We would only query by date logic plus whether the entries are published.

Thinking of it more like a traditional database, you're currently querying status as if it were a column.
With this PR, consider the column gone, and to query by "status" it would really be a more complex query scope.

Breaking changes

In this PR, there should be none. However there will be some for v6 in a separate PR.

At the moment, you can still use all the condition types in your tag or API requests, e.g. status:in="draft|published" or status:not="whatever". It'll query against the stored value like it always did, but you may continue to run into the scheduling bug.

In v6, those will cause exceptions. Similar to if you were to query a missing column in a database you'd get Column [status] not found. In v6 you'll need to use whereStatus.

In v6, you'll only be able to query single statuses. I believe you only ever used the more complex operators to get around issues. I could be wrong! If that's the case and people really need them, we can add them back by making whereStatus smarter, or adding whereStatusIn, etc.

Todo

  • Replace any instances of querying by status
  • In REST API
  • In GraphQL
  • Possibly add some sort of deprecation warning when querying by status
    For this PR, it logs a deprecation message. In v6, it'll throw an exception.
  • Possibly add backwards compatibility for querying by status.
    It's backwards compatible for now because the existing (sometimes broken) behavior will remain unchanged.
  • In a breaking release of eloquent driver, remove the status column. (Drop status on entries eloquent-driver#228)

By the way

This doesn't address the issue where a listing should get updated while using static caching.

That's solvable using https://statamic.com/addons/mity-digital/scheduled-cache-invalidator

# Conflicts:
#	src/Query/StatusQueryBuilder.php
#	src/Stache/Query/EntryQueryBuilder.php
#	tests/Data/Entries/EntryQueryBuilderTest.php
@jasonvarga jasonvarga changed the base branch from 4.x to master April 11, 2024 17:22
@jasonvarga jasonvarga changed the title [4.x] Avoid querying status [5.x] Avoid querying status Apr 11, 2024
@jasonvarga jasonvarga marked this pull request as ready for review April 11, 2024 20:30
@jasonvarga jasonvarga merged commit 32300df into master Apr 11, 2024
31 checks passed
@jasonvarga jasonvarga deleted the avoid-status branch April 11, 2024 20:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Status: Done
Development

Successfully merging this pull request may close these issues.

Stache indexes needs to be able to invalidate at a given time
1 participant