Re: Clarification issue #1510

[Lukas Eder]

Hi Aaron,

> I can't follow you here. If I add a second FK reference to X, I'll have to
> give this column (or columns) a new name, so there can't be a name clash
> (there are no back-references from Y to X generated by this).

No problem. I'll explain:
Assume the following schema:

  CREATE TABLE Y (ID INT PRIMARY KEY);
  CREATE TABLE X (Y_ID INT,
    CONSTRAINT fk1 FOREIGN KEY (Y_ID) REFERENCES Y(ID));

This would generate something like (pseudo-code)

  XRecord {
    // Convenience as you suggested: Y being the table name here.
    void setY(YRecord);
  }

So far, so good. But now, let's add another column:

  ALTER TABLE X ADD ANOTHER_Y_ID INT;
  ALTER TABLE X ADD CONSTRAINT fk2 FOREIGN KEY (ANOTHER_Y_ID) REFERENCES Y(ID);

Regenerate the schema and you'll get

  XRecord {
    void setY(YRecord); // This sets Y_ID
    void setY(YRecord); // This sets ANOTHER_Y_ID
  }

So this convenience wouldn't work anymore. The solution implemented in
2.4.0 generates

  XRecord {
    void setYId(YRecord);
    void setAnotherYId(YRecord);
  }

That is why I'm a bit reluctant to add any heuristics to code
generation. As a user, you know your own DB schema and you can change
things in naming strategies, if the strategy functionality is powerful
enough. But in jOOQ's defaults, stripping the _ID will open some
potential to naming clashes

Let me know if anything remains unclear

Cheers
Lukas