The ORM Foundation

Get the facts!

[Code generation] MySQL doesn't like multiple autoincrement columns

Last post Tue, Jun 21 2011 3:15 by Anonymous. 2 replies.
Page 1 of 1 (3 items)
Sort Posts: Previous Next
  • Mon, Jun 20 2011 5:26

    • janpieter
    • Top 100 Contributor
    • Joined on Tue, Oct 14 2008
    • Groningen, Netherlands
    • Posts 4

    [Code generation] MySQL doesn't like multiple autoincrement columns

    My NORMA 2010-12 for VS 2008 generates excellent normalized MySQL code except for one thing.

    My model contains an entity that plays no roles but its reference scheme. This for the sake of compactness of the model: later it probably will play more roles, but for now, the number is enough.

    As a result this entity is absorbed into the table of another entity. The table now contains to entities with an autoincrement column and MySQL cannot handle this, so it doesn't take the code until the autoincrement property is removed. Or the entity is made independent.

    My questions are: Is this conceptually incorrect (the fact that it plays no roles but its ref mode)?

    Or is it just due to MySQL's limited set of features?

    And of course it would be nice if an error message or different generation would catch this condition.

    Apart from this, the real-time code generation works fine for me and I've use it quite a bit for the static part of the data model.

  • Mon, Jun 20 2011 9:28 In reply to

    • Ken Evans
    • Top 10 Contributor
    • Joined on Sun, Nov 18 2007
    • Stickford, UK
    • Posts 748

    Re: [Code generation] MySQL doesn't like multiple autoincrement columns

    Have you tried to change the "AbsorptionChoice" option in the properties sheet to a value of "Separate"?

    This is explained on page 31 of Tutorial 8.

    Hope this helps.


    Filed under:
  • Tue, Jun 21 2011 3:15 In reply to

    Re: [Code generation] MySQL doesn't like multiple autoincrement columns


    It's a weakness of MySQL which the generators fail to work around. Standard SQL defines sequences which allow this.

    Might I recommend you abandon this toy database? MySQL was written by people who didn't know what a transaction was, and though a lot has been done to improve it, it's still hopelessly antiquated internally. The optimiser is a mid-1980's heuristic design, for example, where every serious DBMS since then has used a cost-based optimiser. Now that Oracle owns MySQL, you can be certain it will never receive a thorough modernisation. I suggest PostreSQL instead.

Page 1 of 1 (3 items)
© 2008-2018 The ORM Foundation: A UK not-for-profit organisation -------------- Terms of Service