Purpose behind 'json_object' => json_encode( $audit ) ?

[angelxmoreno]

My rows are too big, even for longText on MySQL. I am curious what the goal was here especially since the deltas are already tracking what changed.

[robwilkerson]

The goal was simply to provide a snapshot of the integrated object at the time of the change. Doing so means I never have to reassemble the object as it existed at a given point.

[angelxmoreno]

Problem with this approach is that we are saving massive amounts of redundant data. Perhaps a better solution would be the ability to reconstruct the object based on aggregating the deltas.

Currently my records have too much data for me to afford storing them multiple times. I guess another approach would be to extend the behavior and simply not that object.

What are your thoughts? I can get started on a PR.

[robwilkerson]

Life is a trade-off. This approach was easy and didn't have any negative side effects for my needs. :-)

That said, I have no problem progressing beyond that. What I'd like to be sure we have, though, is an easy to call API to retrieve that object snapshot. The developer shouldn't have to reconstruct the object from deltas. I didn't want to do it when I started down this road and that's why I just slapped in the JSON field. I'd like to keep that capability alive.

[angelxmoreno]

sure thing. My company will be making changes and will focus on keeping the existing functionality while at the same time abstract a few parts to add flexibility. We will be sending PRs for your approval as we add these changes.

[robwilkerson]

Let's keep this open and commit against this issue as you all work on the pull request. That should keep things nice and tidy.

[deizel]

Seems another fork has come across this issue also: jippi@de5c3d3

[robwilkerson]

I like that this version retains an option of storing JSON snapshot.

[ravage84]

@xhs345 let's close this and concentrate on #78. This issue is mentioned there, so it's referenced.

[xhs345]

Agree