-
-
Notifications
You must be signed in to change notification settings - Fork 229
Doesn't support long text files #57
Comments
My own experimentation with this has been positive. I've found that simply creating a migration to change the "Modifications" column to mediumtext seems to meet my needs. My concern now is that when I version a large file or script, that there is a lot of duplication in the database. For instance, I have file that is about 3000 lines long. If I make a change to one line of that file, then I see both file get saved in their entirety in the modifications column. I thought that there was an element of this that was only versioning changes? Is there something about this that I'm not understanding? Mike |
I'm working around this by adding a "patch" column to the model that I am versioning. I no longer version the entire script, I only version the patch. The patch is generated using the diff-lcs gem. It is very concise and useful - I can create the patch with this:
The patch is serialized and saved and versioned. When I want to rebuild the file, I step back through the patches:
I was considering creating a fork to put this directly into the plugin - I think that adding an option for :patch, and then modifying revert_to and append_change for patched fields would do it? Or else create before_revert and before_append callbacks to make it easier to add custom processing to columns? Mike |
So, you can filter the columns that are versioned? You filter out the 'body' column, and only allow the 'patch' column to be versioned? Is this workaround still working? Has Vestal Versions implemented something similar in the last ~4 years? |
I'm considering this gem for a version control solution I'm writing. We'll be saving long files in the active record model - including some :medium_text columns.
When I view the database I can see that the "modifications" column is just a "text" field - which I believe cuts off around 64kb in most modern databases. This is too short for my purposes.
Has anyone ever tried to work around this by changing that column type directly?
The text was updated successfully, but these errors were encountered: