Note the 1.29 prescriptive display API change for template authors - #103
Open
chriscoey wants to merge 6 commits into
Open
Note the 1.29 prescriptive display API change for template authors#103chriscoey wants to merge 6 commits into
chriscoey wants to merge 6 commits into
Conversation
…1.29 Templates that call problem.display() are unaffected today (every v1 template pins 1.27.1 or older, none passes the removed part/where/limit arguments, and every solve_for in a template that displays is named), so this adds the migration note authors will need at the point they bump the pin: the removed arguments and their display_string replacement, the null-until-installed behavior of install_display_strings(), the new unnamed-variable ValueError, and the removal of the client-side depth cap. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VxgCY8UfV3awEkrjVwMLqo
display(limit=N) survives the 1.29 change as a whole-problem printer argument; only part= and where= raise TypeError. Also puts the aggregates.limit example in the where-then-select order used elsewhere (both orders work). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VxgCY8UfV3awEkrjVwMLqo
Row ordering moved to a plain-text sort, so display(limit=n) takes a different sample than it did through 1.28. Also drops Expression as a name to reach for; Problem exposes Constraint and Objective. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VxgCY8UfV3awEkrjVwMLqo
|
The templates docs preview for this pull request has been deployed to Vercel!
|
…veats Running these against the 1.29 branch showed three things the pin-bump checklist did not cover: a decision variable declared without name= renders a null display_string even after a correct install; install_display_strings() is scoped to one Problem rather than the model; and the aggregates.limit form orders names as plain text and silently drops constraints that have no name. A constant name= on a per-entity variable also renders every row identically without raising.
Two causes are the common ones, not the only ones, and the render-cost claim is SQL-backend behaviour per the docstring.
The docstring scopes the whole-problem re-render to the SQL backend; the depth cost carries no such qualifier. The note had it in front of the depth clause, which reads as though depth is free elsewhere.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Problem.display()changes in relationalai 1.29. Adds a short section to CONTRIBUTING for anyone bumping a prescriptive template's pin past 1.28.What raises when you bump:
part=andwhere=are gone and raiseTypeError. Select thedisplay_stringproperty on a constraint or objective and filter it with an ordinarywhere.display()raisesValueErrorif any decision variable is unnamed, so passname=to everysolve_for(...). The name has to discriminate too, and that one is silent: a constantname="x"on a per-entity variable renders every constraint identically.The rest are silent:
display_stringhas two common causes needing different fixes: the rendering rules are not installed (onlydisplay()installs them on demand), or a decision variable in the expression was declared withoutname=.install_display_strings()before deploying: the rules have to exist at deploy time.install_display_strings()is scoped to oneProblem, so a template carrying more than one calls it on each.display(limit=n)still works, but samples different rows: row order moved to a plain-text sort, so overx_1..x_12,limit=5givesx_1, x_10, x_11, x_12, x_2where 1.28 gavex_1..x_5. Theaggs.limitform orders the same way, and additionally drops constraints declared withoutname=.<expression too deep>; it renders on the engine instead, and render time climbs steeply with depth.I ran the CONTRIBUTING snippet against the 1.29 branch on the deployment path; it returns what the text says.