I think that would be a prefectly reasonable solution.
It would be more flexible than making a solution that only works on computed columns.
For example, it would work for your columns with are normal except that they are updated by triggers.
And it would make it very explicit (which I like).
--
Chris Phillips
www.dealerpeak.com
Senior Application Developer
On 10/6/06, Sean Corfield <[EMAIL PROTECTED]> wrote:
On 10/4/06, Gareth Cole <[EMAIL PROTECTED]> wrote:
> I was wondering if anyone could help me with this?
>
> When I try to save a record where the table has a computed column, I get the
> error: "Column 'xxxxxxxx' cannot be modified because it is a computed
> column."
FWIW (and I'm sure Doug will hate me for this), Transfer handles this
sort of thing by allowing annotations in the XML that tell the ORM to
ignore columns on insert and/or update and to refresh columns (in the
in-memory object) after insert and/or update. I'm using this with
datecreated / dateupdate columns that are updated by triggers but the
same thing applies here.
In other words, the simplest solution might be for Reactor to require
developer to specify in the XML the fields that should not be inserted
/ updated and/or refreshed from the DB after insert / update
operations.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Reactor for ColdFusion Mailing List
[email protected]
Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Reactor for ColdFusion Mailing List
[email protected]
Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
