Squeryl-Record integration should be Record "dirty_?" field aware #1259

Merged
merged 1 commit into from May 14, 2012

Conversation

Projects
None yet
3 participants
Owner

davewhittaker commented May 8, 2012

Many persistence frameworks (including Lift's Mapper, Lift's Mongodb-Record, ActiveRecord) track which fields have changed their values over record's lifetime since it was populated with data. This allows to reduce overhead when updating rows in database.
This also means that first value assignment should not set the "dirty_?" flag to true (so setFromAny shouldn't be called when the record is being populated for the first time ? or just use Empty value as blank one ?)
This also leaves a question what should be the policy of populating Optional*Fields from Record framework, since there's no information if a field was assigned before (not the case with non optional fields where Empty could mean that first assignment takes place)

As a note: Lift's Mapper fields also keep orgData (original data to track the changes, "protected def i_was_! = orgData")

@ghost ghost assigned davewhittaker Apr 17, 2012

Owner

davewhittaker commented Apr 17, 2012

Ok, just to be clear, my intention is to make it so that the dirty_? flag will not be set ONLY when a field's value is populated from the database. This fix won't result in the dirty_? flag affecting what fields get sent to the DB when Schema.update(obj) is called. I also plan on leaving the current functionality of TypedField.setBox, which means that dirty_? will be true after the user calls that method, regardless of whether the value has actually changed. Will that be a problem for you?

lopex commented Apr 18, 2012

Both of these changes would be insufficient, though I realize how invasive the required changes would be. I think I can work around first one with my own logic (even if it would require me to change squeryl-record or even squeryl itself)
The problem with setBox is that the "data" field is private (now I'm using reflection to get around it). If it was protected then it would be more straight forward by just overriding setBox and using it without reflection hacks. So ultimately, I'll have to change Record on my own too.

I'm well aware of Lift's community and committer policy, and I know that it would be too much to ask for the changes required to make my case work. I'll be happy with the changes you're proposing as well since they'll make my case easier.

Owner

davewhittaker commented Apr 18, 2012

I'm not understanding what else you need. Retrieving a Record and having all of the dirty_? flags set to false isn't enough, please reply to the thread you had started on the google group and provide use cases.

Makes Squeryl-Record both aware of the dirty_? flag, which is reset a…
…fter values are loaded from the DB, and utilize runSafe during data loading.

dpp pushed a commit that referenced this pull request May 14, 2012

Merge pull request #1259 from lift/dw_issue_1259
Squeryl-Record integration should be Record "dirty_?" field aware

@dpp dpp merged commit 33d1e34 into master May 14, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment