You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
remove succeed fast feature (for now, at least) from reference validation, based on discussion with Jules and development of student ID matching bundle
Copy file name to clipboardExpand all lines: README.md
+6-4Lines changed: 6 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -154,16 +154,18 @@ The `references` `method` can be slow, as a separate `GET` request may be made t
154
154
* batching requests and sending several concurrently (based on `connection`.`pool_size` of `lightbeam.yaml`)
155
155
* caching responses and first checking the cache before making another (potentially identical) request
156
156
157
-
Even with these optimizations, checking `references` can easily take minutes for even relatively small amounts of data. Therefore `lightbeam.yaml` also accepts two further configuration options:
157
+
Even with these optimizations, checking `references` can easily take minutes for even relatively small amounts of data. Therefore `lightbeam.yaml` also accepts a further configuration option:
158
158
```yaml
159
159
validate:
160
160
references:
161
161
max_failures: 10 # stop testing after X failed payloads ("fail fast")
162
-
partial: 500 # stop testing if 100% success after X payloads ("succeed fast")
163
162
```
164
-
These are optional; if absent, references in every payload are checked, no matter how many fail or succeed, respectively.
163
+
This is optional; if absent, references in every payload are checked, no matter how many fail.
165
164
166
-
**Note:** Reference validation efficiency may be improved by first `lightbeam fetch`ing certain resources to have a local copy. `lightbeam validate` checks local JSONL files to resolve references before trying the remote API, and `fetch` retrieves many records per `GET`, so total runtime can be faster in this scenario. The downsides are more data movement and the local data becoming stale over time.
165
+
**Note:** Reference validation efficiency may be improved by first `lightbeam fetch`ing certain resources to have a local copy. `lightbeam validate` checks local JSONL files to resolve references before trying the remote API, and `fetch` retrieves many records per `GET`, so total runtime can be faster in this scenario. The downsides include
166
+
* more data movement
167
+
* `fetch`ed data becoming stale over time
168
+
* needing to track which data is your own vs. was `fetch`ed (all the data must coexist in the `config.data_dir` to be discoverable by `lightbeam validate`)
0 commit comments