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 <[EMAIL PROTECTED]> 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 >
