Hi, I noticed that RecordMetaDataFactory uses setFromAny to populate the fields which in turn flags "dirty_?" as true and makes it pretty useless. Do you have an idea how to work it around ?
I'm afraid that whoever originally put the Squeryl Record module together doesn't seem to have been aware of the dirty_? flag. This came up once before, but you are the first person who it seems to be causing a problem for. Can you tell me what you are using the dirty_? flag for? Maybe I can come up with a work around for you.
> Hi, I noticed that RecordMetaDataFactory uses setFromAny to populate the > fields which in turn flags "dirty_?" as true and makes it pretty useless. > Do you have an idea how to work it around ?
I'm working on a more flexible crud for record-squeryl where one can specify fields for list/create/view etc. The problem is with partial update were I want to filter fields based on "dirty_?" flag out. The use case is of course when user changes only one field in the form (the rest gets posted too but the field can check that new value for equality with an old one and leave the "dirty_?" flag intact). Also, the problem becomes more apparent when ajaxified fields are used on list views, one would like to update only one field in the db when doing 'record.save'.
I did similar thing few years ago using Mapper/Crudify and all that logic was in Mapper fields already, worked like a charm.
I'm aware that squeryl can't be made "dirty" aware since it operates on primitive fields, but Record Fields can have more context, you could do then:
class LongField extends .... { def assignment: org.squeryl.dsl.ast.UpdateAssignment = this := get // typsafe assignment for fields
> I'm afraid that whoever originally put the Squeryl Record module > together doesn't seem to have been aware of the dirty_? flag. This > came up once before, but you are the first person who it seems to be > causing a problem for. Can you tell me what you are using the dirty_? > flag for? Maybe I can come up with a work around for you.
> -Dave
> 2012/4/14 Marcin Mielżyński <l...@gazeta.pl <mailto:l...@gazeta.pl>>
> Hi, I noticed that RecordMetaDataFactory uses setFromAny to > populate the fields which in turn flags "dirty_?" as true and > makes it pretty useless. > Do you have an idea how to work it around ?
Interesting. So what you need is for Squeryl to reset the dirty state after retrieving the field values? Sounds reasonable to me. Please open an issue on github referencing this thread and post the issue number back here.
> I'm working on a more flexible crud for record-squeryl where one can > specify fields for list/create/view etc. The problem is with partial update > were I want to filter fields based on "dirty_?" flag out. > The use case is of course when user changes only one field in the form > (the rest gets posted too but the field can check that new value for > equality with an old one and leave the "dirty_?" flag intact). > Also, the problem becomes more apparent when ajaxified fields are used on > list views, one would like to update only one field in the db when doing > 'record.save'.
> I did similar thing few years ago using Mapper/Crudify and all that logic > was in Mapper fields already, worked like a charm.
> I'm aware that squeryl can't be made "dirty" aware since it operates on > primitive fields, but Record Fields can have more context, you could do > then:
> class LongField extends .... { > def assignment: org.squeryl.dsl.ast.UpdateAssignment = this := get // > typsafe assignment for fields > }
> I'm afraid that whoever originally put the Squeryl Record module together > doesn't seem to have been aware of the dirty_? flag. This came up once > before, but you are the first person who it seems to be causing a problem > for. Can you tell me what you are using the dirty_? flag for? Maybe I can > come up with a work around for you.
>> Hi, I noticed that RecordMetaDataFactory uses setFromAny to populate the >> fields which in turn flags "dirty_?" as true and makes it pretty useless. >> Do you have an idea how to work it around ?
My use case (wrt https://github.com/lift/framework/issues/1259) requires two things: 1) having centralized equality check for new value (when the field is being set). This requires having setBox overridden like this:
var dirty__? = false // second dirty value that I control, your fix to have the original one being left untouched while populated will make possible to get rid of this one.
override def setBox(in: Box[T]): Box[T] = { val data = FieldExtensions.dataField.invoke(this).asInstanceOf[Box[T]] if (!data.isEmpty && data != in) dirty__? = true super.setBox(in) }
}
Without direct (or via getter) access I cannot reliably check for comparison since accessors like get/is return "value" method which in turn is "def value: MyType = valueBox openOr defaultValue".
2) being able to abstract over === for id/idField for MetaRecord so I can:
def collectionName = table.name // abstracted to my own MetaRecord so CRUD is not squeryl specific (can be reused for Mongo-Record, etc)
......
def updatePartial(record: BaseRecord) { def assign(rec: BaseRecord): Seq[dsl.ast.UpdateAssignment] = rec.fields.collect{case f: FieldExtensions[_] if f.dirty__? => f}.map(_.assignment) // as "dirty" marker trait for now inTransaction{ // here, although I have all the set assignments in place, I also need "find by id" (I have no idea what constraints should I put here on K to have reasonably typed def ===, I thought about unused now trait KeyField from record) table.update(r => where(r.id === record.id) set(assign(a): _*)
// full update via table.update(o: T)(implicit ev: T <:< KeyedEntity[_]) makes no trouble here since it's delegated to squeryl which doesn't use sql-dsl for it } }
}
To show the whole picture, here is abstracted crudify that doesn't know about squeryl:
// bridge replacements, the brigdes are not needed after all override def buildBridge(in: TheCrudType): CrudBridge = sys.error("buildBridge is turned off") override def buildFieldBridge(from: FieldPointerType): FieldPointerBridge = sys.error("buildFieldBridge is turned off")
def save(record: BaseRecord) = { if (record.isPersisted) { inTransaction{table.update(record)} // I don't want to perform full update here } else { inTransaction{table.insert(record)} } true }
> Interesting. So what you need is for Squeryl to reset the dirty state > after retrieving the field values? Sounds reasonable to me. Please > open an issue on github referencing this thread and post the issue > number back here.
> Thanks, > Dave
> 2012/4/14 Marcin Mielżyński <l...@gazeta.pl <mailto:l...@gazeta.pl>>
> I'm working on a more flexible crud for record-squeryl where one > can specify fields for list/create/view etc. The problem is with > partial update were I want to filter fields based on "dirty_?" > flag out. > The use case is of course when user changes only one field in the > form (the rest gets posted too but the field can check that new > value for equality with an old one and leave the "dirty_?" flag > intact). > Also, the problem becomes more apparent when ajaxified fields are > used on list views, one would like to update only one field in the > db when doing 'record.save'.
> I did similar thing few years ago using Mapper/Crudify and all > that logic was in Mapper fields already, worked like a charm.
> I'm aware that squeryl can't be made "dirty" aware since it > operates on primitive fields, but Record Fields can have more > context, you could do then:
> class LongField extends .... { > def assignment: org.squeryl.dsl.ast.UpdateAssignment = this := > get // typsafe assignment for fields > }
> W dniu 2012-04-14 22:27, David Whittaker pisze: >> I'm afraid that whoever originally put the Squeryl Record module >> together doesn't seem to have been aware of the dirty_? flag. >> This came up once before, but you are the first person who it >> seems to be causing a problem for. Can you tell me what you are >> using the dirty_? flag for? Maybe I can come up with a work >> around for you.
>> -Dave
>> 2012/4/14 Marcin Mielżyński <l...@gazeta.pl <mailto:l...@gazeta.pl>>
>> Hi, I noticed that RecordMetaDataFactory uses setFromAny to >> populate the fields which in turn flags "dirty_?" as true and >> makes it pretty useless. >> Do you have an idea how to work it around ?
I had seen your code before, but rather than digging through it and trying to figure out what you are trying to accomplish, I was hoping for a short description, i.e. "A user posts a form where only some values have changed. Record only marks as dirty the fields that are different. The update call only sends dirty fields to the DB.". Does that about sum it up?
> My use case (wrt https://github.com/lift/framework/issues/1259) requires > two things: > 1) having centralized equality check for new value (when the field is > being set). This requires having setBox overridden like this:
> var dirty__? = false // second dirty value that I control, your fix to > have the original one being left untouched while populated will make > possible to get rid of this one.
> override def setBox(in: Box[T]): Box[T] = { > val data = > FieldExtensions.dataField.invoke(this).asInstanceOf[Box[T]] > if (!data.isEmpty && data != in) dirty__? = true > super.setBox(in) > } > }
> Without direct (or via getter) access I cannot reliably check for > comparison since accessors like get/is return "value" method which in turn > is "def value: MyType = valueBox openOr defaultValue".
> 2) being able to abstract over === for id/idField for MetaRecord so I can:
> def collectionName = table.name // abstracted to my own MetaRecord so > CRUD is not squeryl specific (can be reused for Mongo-Record, etc)
> ......
> def updatePartial(record: BaseRecord) { > def assign(rec: BaseRecord): Seq[dsl.ast.UpdateAssignment] = > rec.fields.collect{case f: FieldExtensions[_] if f.dirty__? => > f}.map(_.assignment) // as "dirty" marker trait for now > inTransaction{ > // here, although I have all the set assignments in place, I > also need "find by id" (I have no idea what constraints should I put here > on K to have reasonably typed def ===, I thought about unused now trait > KeyField from record) > table.update(r => where(r.id === record.id) set(assign(a): _*)
> // full update via table.update(o: T)(implicit ev: T <:< > KeyedEntity[_]) makes no trouble here since it's delegated to squeryl which > doesn't use sql-dsl for it > } > }
> }
> To show the whole picture, here is abstracted crudify that doesn't know > about squeryl:
> // bridge replacements, the brigdes are not needed after all > override def buildBridge(in: TheCrudType): CrudBridge = > sys.error("buildBridge is turned off") > override def buildFieldBridge(from: FieldPointerType): > FieldPointerBridge = sys.error("buildFieldBridge is turned off")
> Interesting. So what you need is for Squeryl to reset the dirty state > after retrieving the field values? Sounds reasonable to me. Please open > an issue on github referencing this thread and post the issue number back > here.
>> I'm working on a more flexible crud for record-squeryl where one can >> specify fields for list/create/view etc. The problem is with partial update >> were I want to filter fields based on "dirty_?" flag out. >> The use case is of course when user changes only one field in the form >> (the rest gets posted too but the field can check that new value for >> equality with an old one and leave the "dirty_?" flag intact). >> Also, the problem becomes more apparent when ajaxified fields are used on >> list views, one would like to update only one field in the db when doing >> 'record.save'.
>> I did similar thing few years ago using Mapper/Crudify and all that logic >> was in Mapper fields already, worked like a charm.
>> I'm aware that squeryl can't be made "dirty" aware since it operates on >> primitive fields, but Record Fields can have more context, you could do >> then:
>> class LongField extends .... { >> def assignment: org.squeryl.dsl.ast.UpdateAssignment = this := get // >> typsafe assignment for fields >> }
>> W dniu 2012-04-14 22:27, David Whittaker pisze:
>> I'm afraid that whoever originally put the Squeryl Record module together >> doesn't seem to have been aware of the dirty_? flag. This came up once >> before, but you are the first person who it seems to be causing a problem >> for. Can you tell me what you are using the dirty_? flag for? Maybe I can >> come up with a work around for you.
>>> Hi, I noticed that RecordMetaDataFactory uses setFromAny to populate the >>> fields which in turn flags "dirty_?" as true and makes it pretty useless. >>> Do you have an idea how to work it around ?
> I had seen your code before, but rather than digging through it and > trying to figure out what you are trying to accomplish, I was hoping > for a short description, i.e. "A user posts a form where only some > values have changed. Record only marks as dirty the fields that are > different. The update call only sends dirty fields to the DB.". Does > that about sum it up?
> 2012/4/18 Marcin Mielżyński <l...@gazeta.pl <mailto:l...@gazeta.pl>>
> My use case (wrt https://github.com/lift/framework/issues/1259) > requires two things: > 1) having centralized equality check for new value (when the field > is being set). This requires having setBox overridden like this:
> var dirty__? = false // second dirty value that I control, > your fix to have the original one being left untouched while > populated will make possible to get rid of this one.
> override def setBox(in: Box[T]): Box[T] = { > val data = > FieldExtensions.dataField.invoke(this).asInstanceOf[Box[T]] > if (!data.isEmpty && data != in) dirty__? = true > super.setBox(in) > } > }
> Without direct (or via getter) access I cannot reliably check for > comparison since accessors like get/is return "value" method which > in turn is "def value: MyType = valueBox openOr defaultValue".
> 2) being able to abstract over === for id/idField for MetaRecord > so I can:
> def collectionName = table.name <http://table.name> // > abstracted to my own MetaRecord so CRUD is not squeryl specific > (can be reused for Mongo-Record, etc)
> ......
> def updatePartial(record: BaseRecord) { > def assign(rec: BaseRecord): Seq[dsl.ast.UpdateAssignment] > = rec.fields.collect{case f: FieldExtensions[_] if f.dirty__? => > f}.map(_.assignment) // as "dirty" marker trait for now > inTransaction{ > // here, although I have all the set assignments in > place, I also need "find by id" (I have no idea what constraints > should I put here on K to have reasonably typed def ===, I thought > about unused now trait KeyField from record) > table.update(r => where(r.id <http://r.id> === > record.id <http://record.id>) set(assign(a): _*)
> // full update via table.update(o: T)(implicit ev: T > <:< KeyedEntity[_]) makes no trouble here since it's delegated to > squeryl which doesn't use sql-dsl for it > } > }
> }
> To show the whole picture, here is abstracted crudify that doesn't > know about squeryl:
> // bridge replacements, the brigdes are not needed after all > override def buildBridge(in: TheCrudType): CrudBridge = > sys.error("buildBridge is turned off") > override def buildFieldBridge(from: FieldPointerType): > FieldPointerBridge = sys.error("buildFieldBridge is turned off")
> W dniu 2012-04-16 17:58, David Whittaker pisze: >> Interesting. So what you need is for Squeryl to reset the dirty >> state after retrieving the field values? Sounds reasonable to >> me. Please open an issue on github referencing this thread and >> post the issue number back here.
>> Thanks, >> Dave
>> 2012/4/14 Marcin Mielżyński <l...@gazeta.pl <mailto:l...@gazeta.pl>>
>> I'm working on a more flexible crud for record-squeryl where >> one can specify fields for list/create/view etc. The problem >> is with partial update were I want to filter fields based on >> "dirty_?" flag out. >> The use case is of course when user changes only one field in >> the form (the rest gets posted too but the field can check >> that new value for equality with an old one and leave the >> "dirty_?" flag intact). >> Also, the problem becomes more apparent when ajaxified fields >> are used on list views, one would like to update only one >> field in the db when doing 'record.save'.
>> I did similar thing few years ago using Mapper/Crudify and >> all that logic was in Mapper fields already, worked like a charm.
>> I'm aware that squeryl can't be made "dirty" aware since it >> operates on primitive fields, but Record Fields can have more >> context, you could do then:
>> class LongField extends .... { >> def assignment: org.squeryl.dsl.ast.UpdateAssignment = >> this := get // typsafe assignment for fields >> }
>> W dniu 2012-04-14 22:27, David Whittaker pisze: >>> I'm afraid that whoever originally put the Squeryl Record >>> module together doesn't seem to have been aware of the >>> dirty_? flag. This came up once before, but you are the >>> first person who it seems to be causing a problem for. Can >>> you tell me what you are using the dirty_? flag for? Maybe >>> I can come up with a work around for you.
>>> -Dave
>>> 2012/4/14 Marcin Mielżyński <l...@gazeta.pl >>> <mailto:l...@gazeta.pl>>
>>> Hi, I noticed that RecordMetaDataFactory uses setFromAny >>> to populate the fields which in turn flags "dirty_?" as >>> true and makes it pretty useless. >>> Do you have an idea how to work it around ?
Ok... I've got a clearer picture now. I think. I'll make the updates to
Squeryl-Record soon so that the fields don't begin in the dirty state.
Implementing a check regarding whether a value has really changed when a
Record Field is updated is a bit more involved though. I'd like to think
that Record.set_! could be modified so that it performs an == chacke,
rather than setting dirty true whenever setBox is called. I'm hesitant to
make that change though since I don't know what affect it might have on
other Record modules like Mongo. I'm going to think about this one and get
back to you.
> Essentially yes (or even being able to choose between full and partial
> updates), the posted code was to show why I care.
> Thanks.
> W dniu 2012-04-19 15:52, David Whittaker pisze:
> Marcin,
> I had seen your code before, but rather than digging through it and
> trying to figure out what you are trying to accomplish, I was hoping for a
> short description, i.e. "A user posts a form where only some values have
> changed. Record only marks as dirty the fields that are different. The
> update call only sends dirty fields to the DB.". Does that about sum it up?
>> My use case (wrt https://github.com/lift/framework/issues/1259)
>> requires two things:
>> 1) having centralized equality check for new value (when the field is
>> being set). This requires having setBox overridden like this:
>> var dirty__? = false // second dirty value that I control, your fix
>> to have the original one being left untouched while populated will make
>> possible to get rid of this one.
>> override def setBox(in: Box[T]): Box[T] = {
>> val data =
>> FieldExtensions.dataField.invoke(this).asInstanceOf[Box[T]]
>> if (!data.isEmpty && data != in) dirty__? = true
>> super.setBox(in)
>> }
>> }
>> Without direct (or via getter) access I cannot reliably check for
>> comparison since accessors like get/is return "value" method which in turn
>> is "def value: MyType = valueBox openOr defaultValue".
>> 2) being able to abstract over === for id/idField for MetaRecord so I can:
>> def collectionName = table.name // abstracted to my own MetaRecord
>> so CRUD is not squeryl specific (can be reused for Mongo-Record, etc)
>> ......
>> def updatePartial(record: BaseRecord) {
>> def assign(rec: BaseRecord): Seq[dsl.ast.UpdateAssignment] =
>> rec.fields.collect{case f: FieldExtensions[_] if f.dirty__? =>
>> f}.map(_.assignment) // as "dirty" marker trait for now
>> inTransaction{
>> // here, although I have all the set assignments in place, I
>> also need "find by id" (I have no idea what constraints should I put here
>> on K to have reasonably typed def ===, I thought about unused now trait
>> KeyField from record)
>> table.update(r => where(r.id === record.id) set(assign(a):
>> _*)
>> // full update via table.update(o: T)(implicit ev: T <:<
>> KeyedEntity[_]) makes no trouble here since it's delegated to squeryl which
>> doesn't use sql-dsl for it
>> }
>> }
>> }
>> To show the whole picture, here is abstracted crudify that doesn't know
>> about squeryl:
>> // bridge replacements, the brigdes are not needed after all
>> override def buildBridge(in: TheCrudType): CrudBridge =
>> sys.error("buildBridge is turned off")
>> override def buildFieldBridge(from: FieldPointerType):
>> FieldPointerBridge = sys.error("buildFieldBridge is turned off")
>> W dniu 2012-04-16 17:58, David Whittaker pisze:
>> Interesting. So what you need is for Squeryl to reset the dirty state
>> after retrieving the field values? Sounds reasonable to me. Please open
>> an issue on github referencing this thread and post the issue number back
>> here.
>>> I'm working on a more flexible crud for record-squeryl where one can
>>> specify fields for list/create/view etc. The problem is with partial update
>>> were I want to filter fields based on "dirty_?" flag out.
>>> The use case is of course when user changes only one field in the form
>>> (the rest gets posted too but the field can check that new value for
>>> equality with an old one and leave the "dirty_?" flag intact).
>>> Also, the problem becomes more apparent when ajaxified fields are used
>>> on list views, one would like to update only one field in the db when doing
>>> 'record.save'.
>>> I did similar thing few years ago using Mapper/Crudify and all that
>>> logic was in Mapper fields already, worked like a charm.
>>> I'm aware that squeryl can't be made "dirty" aware since it operates on
>>> primitive fields, but Record Fields can have more context, you could do
>>> then:
>>> class LongField extends .... {
>>> def assignment: org.squeryl.dsl.ast.UpdateAssignment = this := get //
>>> typsafe assignment for fields
>>> }
>>> W dniu 2012-04-14 22:27, David Whittaker pisze:
>>> I'm afraid that whoever originally put the Squeryl Record module
>>> together doesn't seem to have been aware of the dirty_? flag. This came up
>>> once before, but you are the first person who it seems to be causing a
>>> problem for. Can you tell me what you are using the dirty_? flag for?
>>> Maybe I can come up with a work around for you.
>>>> Hi, I noticed that RecordMetaDataFactory uses setFromAny to populate
>>>> the fields which in turn flags "dirty_?" as true and makes it pretty
>>>> useless.
>>>> Do you have an idea how to work it around ?
> Ok... I've got a clearer picture now. I think. I'll make the updates > to Squeryl-Record soon so that the fields don't begin in the dirty > state. Implementing a check regarding whether a value has really > changed when a Record Field is updated is a bit more involved though. > I'd like to think that Record.set_! could be modified so that it > performs an == chacke, rather than setting dirty true whenever setBox > is called. I'm hesitant to make that change though since I don't know > what affect it might have on other Record modules like Mongo. I'm > going to think about this one and get back to you.
> 2012/4/19 Marcin Mielżyński <l...@gazeta.pl <mailto:l...@gazeta.pl>>
> Essentially yes (or even being able to choose between full and
> partial updates), the posted code was to show why I care.
> Thanks.
> W dniu 2012-04-19 15:52, David Whittaker pisze:
>> Marcin,
>> I had seen your code before, but rather than digging through it
>> and trying to figure out what you are trying to accomplish, I was
>> hoping for a short description, i.e. "A user posts a form where
>> only some values have changed. Record only marks as dirty the
>> fields that are different. The update call only sends dirty
>> fields to the DB.". Does that about sum it up?
>> 2012/4/18 Marcin Mielżyński <l...@gazeta.pl <mailto:l...@gazeta.pl>>
>> My use case (wrt
>> https://github.com/lift/framework/issues/1259) requires two
>> things:
>> 1) having centralized equality check for new value (when the
>> field is being set). This requires having setBox overridden
>> like this:
>> var dirty__? = false // second dirty value that I
>> control, your fix to have the original one being left
>> untouched while populated will make possible to get rid of
>> this one.
>> override def setBox(in: Box[T]): Box[T] = {
>> val data =
>> FieldExtensions.dataField.invoke(this).asInstanceOf[Box[T]]
>> if (!data.isEmpty && data != in) dirty__? = true
>> super.setBox(in)
>> }
>> }
>> Without direct (or via getter) access I cannot reliably check
>> for comparison since accessors like get/is return "value"
>> method which in turn is "def value: MyType = valueBox openOr
>> defaultValue".
>> 2) being able to abstract over === for id/idField for
>> MetaRecord so I can:
>> def collectionName = table.name <http://table.name> //
>> abstracted to my own MetaRecord so CRUD is not squeryl
>> specific (can be reused for Mongo-Record, etc)
>> ......
>> def updatePartial(record: BaseRecord) {
>> def assign(rec: BaseRecord):
>> Seq[dsl.ast.UpdateAssignment] = rec.fields.collect{case f:
>> FieldExtensions[_] if f.dirty__? => f}.map(_.assignment) //
>> as "dirty" marker trait for now
>> inTransaction{
>> // here, although I have all the set assignments
>> in place, I also need "find by id" (I have no idea what
>> constraints should I put here on K to have reasonably typed
>> def ===, I thought about unused now trait KeyField from record)
>> table.update(r => where(r.id <http://r.id> ===
>> record.id <http://record.id>) set(assign(a): _*)
>> // full update via table.update(o: T)(implicit
>> ev: T <:< KeyedEntity[_]) makes no trouble here since it's
>> delegated to squeryl which doesn't use sql-dsl for it
>> }
>> }
>> }
>> To show the whole picture, here is abstracted crudify that
>> doesn't know about squeryl:
>> // bridge replacements, the brigdes are not needed after all
>> override def buildBridge(in: TheCrudType): CrudBridge =
>> sys.error("buildBridge is turned off")
>> override def buildFieldBridge(from: FieldPointerType):
>> FieldPointerBridge = sys.error("buildFieldBridge is turned off")
>> W dniu 2012-04-16 17:58, David Whittaker pisze:
>>> Interesting. So what you need is for Squeryl to reset the
>>> dirty state after retrieving the field values? Sounds
>>> reasonable to me. Please open an issue on github
>>> referencing this thread and post the issue number back here.
>>> Thanks,
>>> Dave
>>> 2012/4/14 Marcin Mielżyński <l...@gazeta.pl
>>> <mailto:l...@gazeta.pl>>
>>> I'm working on a more flexible crud for record-squeryl
>>> where one can specify fields for list/create/view etc.
>>> The problem is with partial update were I want to filter
>>> fields based on "dirty_?" flag out.
>>> The use case is of course when user changes only one
>>> field in the form (the rest gets posted too but the
>>> field can check that new value for equality with an old
>>> one and leave the "dirty_?" flag intact).
>>> Also, the problem becomes more apparent when ajaxified
>>> fields are used on list views, one would like to update
>>> only one field in the db when doing 'record.save'.
On Tue, May 8, 2012 at 1:40 PM, Marcin Mielżyński <l...@gazeta.pl> wrote:
> Thank you! That's really appreciated.
> W dniu 2012-04-24 16:41, David Whittaker pisze:
> Hi Marcin,
> Ok... I've got a clearer picture now. I think. I'll make the updates
> to Squeryl-Record soon so that the fields don't begin in the dirty state.
> Implementing a check regarding whether a value has really changed when a
> Record Field is updated is a bit more involved though. I'd like to think
> that Record.set_! could be modified so that it performs an == chacke,
> rather than setting dirty true whenever setBox is called. I'm hesitant to
> make that change though since I don't know what affect it might have on
> other Record modules like Mongo. I'm going to think about this one and get
> back to you.
>> Essentially yes (or even being able to choose between full and partial
>> updates), the posted code was to show why I care.
>> Thanks.
>> W dniu 2012-04-19 15:52, David Whittaker pisze:
>> Marcin,
>> I had seen your code before, but rather than digging through it and
>> trying to figure out what you are trying to accomplish, I was hoping for a
>> short description, i.e. "A user posts a form where only some values have
>> changed. Record only marks as dirty the fields that are different. The
>> update call only sends dirty fields to the DB.". Does that about sum it up?
>>> My use case (wrt https://github.com/lift/framework/issues/1259)
>>> requires two things:
>>> 1) having centralized equality check for new value (when the field is
>>> being set). This requires having setBox overridden like this:
>>> var dirty__? = false // second dirty value that I control, your fix
>>> to have the original one being left untouched while populated will make
>>> possible to get rid of this one.
>>> override def setBox(in: Box[T]): Box[T] = {
>>> val data =
>>> FieldExtensions.dataField.invoke(this).asInstanceOf[Box[T]]
>>> if (!data.isEmpty && data != in) dirty__? = true
>>> super.setBox(in)
>>> }
>>> }
>>> Without direct (or via getter) access I cannot reliably check for
>>> comparison since accessors like get/is return "value" method which in turn
>>> is "def value: MyType = valueBox openOr defaultValue".
>>> 2) being able to abstract over === for id/idField for MetaRecord so I
>>> can:
>>> def collectionName = table.name // abstracted to my own MetaRecord
>>> so CRUD is not squeryl specific (can be reused for Mongo-Record, etc)
>>> ......
>>> def updatePartial(record: BaseRecord) {
>>> def assign(rec: BaseRecord): Seq[dsl.ast.UpdateAssignment] =
>>> rec.fields.collect{case f: FieldExtensions[_] if f.dirty__? =>
>>> f}.map(_.assignment) // as "dirty" marker trait for now
>>> inTransaction{
>>> // here, although I have all the set assignments in place, I
>>> also need "find by id" (I have no idea what constraints should I put here
>>> on K to have reasonably typed def ===, I thought about unused now trait
>>> KeyField from record)
>>> table.update(r => where(r.id === record.id) set(assign(a):
>>> _*)
>>> // full update via table.update(o: T)(implicit ev: T <:<
>>> KeyedEntity[_]) makes no trouble here since it's delegated to squeryl which
>>> doesn't use sql-dsl for it
>>> }
>>> }
>>> }
>>> To show the whole picture, here is abstracted crudify that doesn't know
>>> about squeryl:
>>> // bridge replacements, the brigdes are not needed after all
>>> override def buildBridge(in: TheCrudType): CrudBridge =
>>> sys.error("buildBridge is turned off")
>>> override def buildFieldBridge(from: FieldPointerType):
>>> FieldPointerBridge = sys.error("buildFieldBridge is turned off")
>>> W dniu 2012-04-16 17:58, David Whittaker pisze:
>>> Interesting. So what you need is for Squeryl to reset the dirty state
>>> after retrieving the field values? Sounds reasonable to me. Please open
>>> an issue on github referencing this thread and post the issue number back
>>> here.
>>>> I'm working on a more flexible crud for record-squeryl where one can
>>>> specify fields for list/create/view etc. The problem is with partial update
>>>> were I want to filter fields based on "dirty_?" flag out.
>>>> The use case is of course when user changes only one field in the form
>>>> (the rest gets posted too but the field can check that new value for
>>>> equality with an old one and leave the "dirty_?" flag intact).
>>>> Also, the problem becomes more apparent when ajaxified fields are used
>>>> on list views, one would like to update only one field in the db when doing
>>>> 'record.save'.
>>>> I did similar thing few years ago using Mapper/Crudify and all that
>>>> logic was in Mapper fields already, worked like a charm.
>>>> I'm aware that squeryl can't be made "dirty" aware since it operates on
>>>> primitive fields, but Record Fields can have more context, you could do
>>>> then:
>>>> class LongField extends .... {
>>>> def assignment: org.squeryl.dsl.ast.UpdateAssignment = this := get
>>>> // typsafe assignment for fields
>>>> }
>>>> W dniu 2012-04-14 22:27, David Whittaker pisze:
>>>> I'm afraid that whoever originally put the Squeryl Record module
>>>> together doesn't seem to have been aware of the dirty_? flag. This came up
>>>> once before, but you are the first person who it seems to be causing a
>>>> problem for. Can you tell me what you are using the dirty_? flag for?
>>>> Maybe I can come up with a work around for you.
