I’m currently working on implementing a system to track liquid classes in git, to allow for version control as well as ensure consistency between instruments. I’m interested to hear what solutions others have seen/built for this sort of thing. The goal is to allow for tracking changes to individual liquid classes, as opposed to just chucking the whole binary file into version control.
To accomplish this, my approach was to dump the liquid class database to a csv, track that csv in git, and then update the database on the other end based on the csv. I have a proof of concept working, but after rebuilding the database I’m getting some pretty esoteric errors in CO-RE Liquid Editor when trying to edit or create liquid classes. Figured I’d see if anyone here had built something like this in the past before diving too deep down the rabbit hole.
1 Like
i am really interested in this approach. what is the problem you are running into?
There was one other error that I didn’t grab a screenshot of at the time, but in general it was things like the following, even when the tables looked identical to a working copy of the db:
I’ve since resolved those issues by diffing the old and new csvs, and only adding/removing/changing the entries in the db that have actually changed. My previous approach for the proof of concept was to remove all records from the table and then recreate all of them based on the new csv, which was leading to the cryptic errors.
The main issue I’m running into at the moment is that the fields LiquidNotes, CorrectionCurve, and DesignHistory are of type OLE Object (aka binary blob) instead of Text or Number, and therefore difficult to write/read to/from a csv. I’m working on writing those fields to their own temporary
binary files which can then be read for the SQL update/insert, but haven’t gotten this to function correctly yet.