Re: Re: DB_DataObjects save method

On Fri, 29 Oct 2004 16:49:20 -0400, Hans L <hans@velum.net> wrote: > Hi, > > Arthur Hundiak wrote: > > A nice option would to have the UPDATE operation first do a SELECT and then > > only update the record if something has actually changed. The idea is that > > a select is generally faster than an update so performance can be improved > > by avoiding unnecessary updates. Of course it has to be optional since > > sometimes you know for certain the record has changed. > > Another option here (again, a Propel thing, sorry) is to just store the > columns that change. I'm trying to remember ... doesn't DBDO use the > overload methods __set() and __get() to store the db info? So I guess > in those methods you could store the modified columns (?). Only when you use it. It also allows direct setting/getting esp. for those of us on PHP4 where overloading either crashes PHP or breaks pass-by-ref. This simply would not work unless DO enforced this method of doing things. > > To illustrate, with typical mutator method: > > function setName($v) { > if ($v !== $this->name) { > $this->modifiedColumns[] = "name"; > $this->name = $v; > } > } > > That way when you actually perform the UPDATE, you can quickly build the > column list from the $modifiedColumns array. Plus this give you an easy > way to check whether objects are modified: $obj->isModified() or > $obj->getModifiedColumns(). > > Probably something similar would be possible in __get() method. > > Of course this doesn't account for possibility that someone else changed > record in the background, but PHP in general is going to suck at those > scenarious without an SRM solution and lots of hard-to-debug code to > debug persistence code. Doing a SELECT before the update would be > possible, but would add a lot of overhead. Plus this approach would > have to account for the fact that databases sometimes transform values > (e.g. date/time values might change formats once inserted). > -- paperCrane --Justin Patrin--