docs: fix wording, fix Rails floor - #46
Conversation
An audit against the common markers of AI-generated prose found five small instances: the two em dashes in the README opening, the word "excellent" in two places, the vague "modern DML support", and an abstract cross-reference sentence in the state migration guide. Each is rewritten in Simplified Technical English with the specific fact the vague word hid: SQLite 3.35 is the floor because of RETURNING. The audit also found one stale claim: the Solid Queue research notes still said the gem requires Rails 8.0 because of the SQLite immediate-transaction default. The floor moved to Rails 7.1 in c67797d, and the suite passes on 7.1 and 7.2 with the deferred default, so the entry now records the real constraint: Rails 7.0 pins sqlite3 1.4, which lacks the busy-handler control this gem depends on.
Greptile SummaryThis documentation-only PR improves introductory prose and corrects the documented Rails and SQLite compatibility floors.
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains. Important Files Changed
Reviews (2): Last reviewed commit: "docs: state the SQLite floor without a r..." | Re-trigger Greptile |
| - MySQL documentation inspected was MySQL 8.4. Solid Objects supports MySQL 8.0 and newer with InnoDB. | ||
| - SQLite documentation inspected covers current SQLite behavior. Solid Objects requires SQLite 3.35 or newer for modern DML support. | ||
| - Rails documentation and source inspected cover Rails 8.1. Solid Objects requires Rails 8.0 or newer because Rails 8 changed the SQLite adapter's default write transaction from deferred to immediate, which the SQLite coordination contract relies on. | ||
| - SQLite documentation inspected covers current SQLite behavior. Solid Objects requires SQLite 3.35 or newer for `RETURNING` support. |
There was a problem hiding this comment.
Incorrect SQLite floor rationale
This attributes the SQLite 3.35 floor to RETURNING, but Solid Objects does not use that feature and the adapter documentation associates SQLite support with serialized write transactions. The explanation therefore gives readers an inaccurate basis for compatibility and design decisions.
| - SQLite documentation inspected covers current SQLite behavior. Solid Objects requires SQLite 3.35 or newer for `RETURNING` support. | |
| - SQLite documentation inspected covers current SQLite behavior. Solid Objects supports SQLite 3.35 or newer. |
Knowledge Base Used: Configuration and database adapters
Prompt To Fix With AI
This is a comment left during a code review.
Path: docs/research/solid_queue.md
Line: 529
Comment:
**Incorrect SQLite floor rationale**
This attributes the SQLite 3.35 floor to `RETURNING`, but Solid Objects does not use that feature and the adapter documentation associates SQLite support with serialized write transactions. The explanation therefore gives readers an inaccurate basis for compatibility and design decisions.
```suggestion
- SQLite documentation inspected covers current SQLite behavior. Solid Objects supports SQLite 3.35 or newer.
```
**Knowledge Base Used:** [Configuration and database adapters](https://app.greptile.com/craftsmanfounder/-/custom-context/knowledge-base/cardmagic/solid_objects/-/docs/configuration-and-database-adapters.md)
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
Review found the previous edit attributed the 3.35 floor to RETURNING, which the code never uses. The floor is the oldest server version the adapter's startup check accepts (201fd33), not a single-feature requirement, so the entry now states the supported version without inventing a reason.
Improve prose