Brian Kotek wrote:
On the last point, you're misunderstanding me. Reactor isn't trying to
INSERT the same row with the same primary key twice. It is UPDATING the
same row. But when Reactor does the update via a DAO, it updates ALL the
columns. Reactor has no way of knowing which columns have changed so it
assumes that they all have potentially changed, and creates the update
statement accordingly. Some of the columns may contain the same values
that are already in the table (like the primary key) but they are still
included in the update statement.
It is true that Reactor *does* this -- but that doesn't mean it makes sense.
Given a simple table:
table: test
------------
ID primary-key, int
data text
.save() on a dirty testRecord creates SQL equivalent to:
update test set ID=#ID#, data=#data" where ID=#ID#
Including the primary-key in the set-statements is not merely
*sometimes* updating to the same value that was already stored -- it
*ALWAYS* updates ID to have the value it already had, the
where-statement ensures that.
No matter the value of old and new ID, including the primary-key in the
columns to be updated is superfluous. Better would be:
update test set data=#data" where ID=#ID#
i.e. include all fields EXCEPT the primary-key. (or those that are part
of the primary-key in the case of multiple fields forming the primary-key)
Unless I'm mistaken, this would break nothing, potentially make things
sligthly faster, and make non-updatable primary-keys (like the
rowguidcols) automagically work.
Eivind Kjørstad
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Reactor for ColdFusion Mailing List
[email protected]
Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
