Thinking about this some more, obviously can't update PK fields with
the approach in Reactor. We'd have to store the previous values some
how in the bean! duh!
So, with that, I'll suggest modifying reactor/xsl/dao.project.xsl
lines 193-209 with the following code. This will cause a predictable
error to be thrown if a update() is attempted on a record that has all
attributes as a PK. Maybe there's a better error message? Note, this
is DB independent.
<xsl:choose>
<xsl:when test="count(object/fields/[EMAIL PROTECTED] =
'false']) = 0" >
<cfthrow message="Nothing to Update"
detail="There are no
non-primary key fields to update."
type="Reactor.Record.NothingToUpdate" />
</xsl:when>
<xsl:otherwise>
<xsl:for-each select="object/fields/[EMAIL
PROTECTED] = 'false']">
#Convention.formatUpdateFieldName('<xsl:value-of select="@name"
/>')# = <cfqueryparam
cfsqltype="<xsl:value-of
select="@cfSqlType" />"
<xsl:if test="@length > 0 and
@cfSqlType != 'cf_sql_longvarchar'">
scale="<xsl:value-of
select="@length" />"
</xsl:if>
value="<xsl:choose>
<xsl:when
test="@dbDataType =
'uniqueidentifier'">#Left(arguments.to.<xsl:value-of select="@alias"
/>, 23)#-#Right(arguments.to.<xsl:value-of select="@alias" />,
12)#</xsl:when>
<xsl:otherwise>#arguments.to.<xsl:value-of select="@alias"
/>#</xsl:otherwise>
</xsl:choose>"
<xsl:if test="@nullable =
'true'">
null="#Iif(NOT
Len(arguments.to.<xsl:value-of select="@alias"
/>), DE(true), DE(false))#"
</xsl:if> />
<xsl:if test="position() !=
last()">
<xsl:text>,</xsl:text>
</xsl:if>
</xsl:for-each>
</xsl:otherwise>
</xsl:choose>
thoughts?
DK
On 5/19/06, Douglas Knudsen <[EMAIL PROTECTED]> wrote:
ok, so I can modify the file reactor/xsl/dao.project.xsl adding in a
wee bit to the section controlling creation of the DAOs update method.
Works for me, but for the rest of the world that doesn't use Oracle I
dunno. Maybe everyone should just use Oracle? ha!! Old Steve would
like that , eh?
I thought about whether this is a good thing or not too. Would it be
better to in this sort of case, not create a update? Or maybe its
better to maek the update() method actually perform a delete() then a
create()?
I know Doug is out and all, and he better stay away, eh? I've never
really gotten involved with this sort of thing. How to contribute
here?
DK
> >
> > On 5/19/06, Douglas Knudsen <[EMAIL PROTECTED]> wrote:
> > > I have a table called mytable say with two columns fkone and fktwo.
> > > This table is a so called link table and both columns comprise the
> > > primary key. I'm using Oracle BTW. Looking at the DAO for this table
> > > generated by reactor I see SQL like this
> > >
> > > UPDATE mytable
> > > SET
> > > WHERE
> > > fkone = ...
> > > AND
> > > fktwo = ....
> > >
> > > obviously this bombs out when I try to perform a save() on the mytable
> > > object. Am I breaking a best practise here? Or is this a bug of some
> > > sort?
> > >
> > > --
> > > Douglas Knudsen
> > > http://www.cubicleman.com
> > > this is my signature, like it?
> > >
> > >
> > >
> > > -- 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/
> >
> >
> >
>
>
> --
> Douglas Knudsen
> http://www.cubicleman.com
> this is my signature, like it?
>
--
Douglas Knudsen
http://www.cubicleman.com
this is my signature, like it?
--
Douglas Knudsen
http://www.cubicleman.com
this is my signature, like it?
-- Reactor for ColdFusion Mailing List -- [email protected]
-- Archives at http://www.mail-archive.com/reactor%40doughughes.net/
