hasura / hasura/graphql-engine
Post Update Check with impacted Views
- Dominant language
- TypeScript
- Stars
- 32.1k
- Forks
- 3k
- PR merge metrics
- PR metrics pending
Description
### Version Information
Server Version: 2.10.1
CLI Version (for CLI related issue):
### Environment
EE
### What is the current behaviour?
Post Update Check is not correct when the condition is based on a view that gets impacted by the update.
Example:
Consider:
User table with field for status:
User,Status
User1,active
User2,inactive
User3,inactive
View to count active users:
status,count
active,1
inactive,2
For post update check, condition is specified as
status -eq active, and count < 3
with above condition,
if we updateByQuery to mark both User2, and User3 to active in the same call, the update succeeds, while it should not since post update the active count becomes 3 and the condition does not satisfy.
### What is the expected behaviour?
Updates should fail if post update check fails.
### How to reproduce the issue?
1. Create Table User, add users as shown abovw
2. Create View as shown above
3. Enable update mutation with rule as active user count < 3
4. bulk update users table to mark all users as active
### Screenshots or Screencast
### Please provide any traces or logs that could help here.
### Any possible solutions?
### Can you identify the location in the source code where the problem exists?
### If the bug is confirmed, would you be willing to submit a PR?
### Keywords
post-update check
Contributor guide
Research direction
Reproduce the update mutation using the User table, the impacted view, and the post-update condition described in the issue. Start by tracing post-update check handling for bulk updates and how impacted views are evaluated. Done means the update fails when the resulting view count violates the condition, with regression coverage for the described case.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- postgres
- Domain
- backend-api-design, databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100