Abator problem updating table with unique key constraint but no primary keay

[Robert Glover <ro...@yahoo.com>]

   The Abator update shown below will not compile because Abator will not
generate the "updateByPrimary" method.

   The reason Abator will not generate the "updateByPrimary" method is that the
table has a "unique" constraint on a column but does not define that column as
being a primary key. (The table has no primary key defined at all).

    I cannot solve this problem by dropping the "unique" constraint and
replacing it with a primary key definition on the same column.  There are two
reasons why I can't.  First, because an "ALTER" statement to define a primary
key fails because there is already a "unique" constraint defined.  Second,
because an "ALTER" to drop the "unique" constraint fails due to there being
foreign keys in other tables that reference that column.

     Here is the Abator method I cannot compile because Abator does not
generate the method due to their being no primary key:


getIatMidOrgStructureDAO().updateByPrimary(iatMidOrgStructure2);


      Is there any change I can make to the Abator XML to force it to generate
that method.

       A second question I have is that I do not fully understand the
difference between the Abator method "updateByPrimaryKey"  versus the Abator
method "updateByPrimaryKeySelective".  My guess is that the latter only creates
"SET" statements for columns that have a non-null value.

tx (and tx for the answer to a previous question about surrounding column names
with literals, a feature that will appear in an upcoming Abator release),
Robert

Re: Abator problem updating table with unique key constraint but no primary keay

[Jeff Butler <je...@gmail.com>]

There's no way to force Abator to generate an updateByPrimaryKey method if
there's not a primary key in the table.  This issue has come up before - but
the problem is a failure in database design more so than a failure of
Abator.

However, the next version of Abator will generate an updateByExample method
that will overcome this issue once and for all.  I'm working on that now but
it's not in SVN yet.  I'm trying to decide about the best way to code around
an iBATIS bug before I commit anything.

As far as the updateXXXSelective methods, you are correct.  The selective
methods will only generate set statements for non-null values in the
parameter object.

Jeff Butler


On 9/20/07, Robert Glover <ro...@yahoo.com> wrote:
>
>   The Abator update shown below will not compile because Abator will not
> generate the "updateByPrimary" method.
>
>   The reason Abator will not generate the "updateByPrimary" method is that
> the
> table has a "unique" constraint on a column but does not define that
> column as
> being a primary key. (The table has no primary key defined at all).
>
>    I cannot solve this problem by dropping the "unique" constraint and
> replacing it with a primary key definition on the same column.  There are
> two
> reasons why I can't.  First, because an "ALTER" statement to define a
> primary
> key fails because there is already a "unique" constraint defined.  Second,
> because an "ALTER" to drop the "unique" constraint fails due to there
> being
> foreign keys in other tables that reference that column.
>
>     Here is the Abator method I cannot compile because Abator does not
> generate the method due to their being no primary key:
>
>
> getIatMidOrgStructureDAO().updateByPrimary(iatMidOrgStructure2);
>
>
>      Is there any change I can make to the Abator XML to force it to
> generate
> that method.
>
>       A second question I have is that I do not fully understand the
> difference between the Abator method "updateByPrimaryKey"  versus the
> Abator
> method "updateByPrimaryKeySelective".  My guess is that the latter only
> creates
> "SET" statements for columns that have a non-null value.
>
> tx (and tx for the answer to a previous question about surrounding column
> names
> with literals, a feature that will appear in an upcoming Abator release),
> Robert
>