Re: Re: DB_DataObjects save method
| From: | Hans L | Date: | Fri, 29 Oct 2004 20:49:20 +0000 |
| Subject: | Re: Re: DB_DataObjects save method | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-34163@lists.php.net to get a copy of this message | ||
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 (?). 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).
Cheers,
Hans