Comments
2 comments
-
Hi @SimonBarnes,
I suspect that this is possible to update by:- Unlinking the static data
- Committing
- Relinking the static data
Kendra -
I definitely unlinked and relinked, but I don't think I committed in between. I've tested it again and I can't replicate exactly what I was experiencing so I think it may have been a temporary wonk.
However when testing it I found that (without unlinking) a change is detected on the static data file, but it doesn't pick up the new column name and wants to replace all values in the old (no longer existent) column with NULLs. I think that's part of an existing problem WRT how Source Control deals with renames (and indeed whether it can detect them as renames at all), but the steps you've outlined above definitely suffice in getting the static data file back into shape — I'd forgotten that an unlink actually generates an entry in the next commit to delete the file, so now I've got that straight in my head I should remember for the future.
Thanks!
Add comment
Please sign in to leave a comment.
I suspect that it's basing its decision purely on whether a delta in the data has been observed. I think it might be wise to have Source Control regenerate the static data script text any time a static data-linked table has a schema or data change, and then just diff it against what's in the repo to decide whether there's a change.