|
7 | 7 | from datajoint.jobs import ERROR_MESSAGE_LENGTH, TRUNCATION_APPENDIX |
8 | 8 |
|
9 | 9 | from tests import schema |
| 10 | +from tests.schema_uuid import BasicComputed |
10 | 11 |
|
11 | 12 |
|
12 | 13 | def test_reserve_job(clean_jobs, subject, experiment): |
@@ -206,3 +207,26 @@ def test_jobs_refresh_with_keep_completed(clean_jobs, subject, experiment): |
206 | 207 |
|
207 | 208 | # Calling refresh again should not raise semantic matching error |
208 | 209 | experiment.jobs.refresh() # This was failing before the fix |
| 210 | + |
| 211 | + |
| 212 | +def test_jobs_table_uuid_fk_derived_pk(schema_uuid): |
| 213 | + """Jobs table generation must handle uuid-typed FK-derived primary keys (#1515). |
| 214 | +
|
| 215 | + The auto-generated jobs table definition previously leaked the resolved SQL |
| 216 | + type (binary(16)) for a uuid PK attribute instead of the DataJoint alias |
| 217 | + (uuid), so declaring the ~~table raised |
| 218 | + "Unsupported attribute type binary(16)" on first .jobs access. |
| 219 | + """ |
| 220 | + # Definition must carry the DataJoint alias, not the resolved SQL type. |
| 221 | + definition = BasicComputed.jobs.definition |
| 222 | + assert "uuid" in definition |
| 223 | + assert "binary(16)" not in definition |
| 224 | + |
| 225 | + # First .jobs access declares the ~~table; this is where the bug fired. |
| 226 | + BasicComputed.jobs.refresh() |
| 227 | + assert BasicComputed.jobs.is_declared |
| 228 | + |
| 229 | + # The declared PK attribute round-trips back to uuid / binary(16). |
| 230 | + pk = BasicComputed.jobs.heading.primary_key |
| 231 | + assert "item" in pk |
| 232 | + assert BasicComputed.jobs.heading["item"].original_type == "uuid" |
0 commit comments