in

The ORM Foundation

Get the facts!

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

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

    • janpieter
    • Top 100 Contributor
      Male
    • Joined on 10-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.

  • 06-20-2011 9:28 In reply to

    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.

    Ken 

    Filed under:
  • 06-21-2011 3:15 In reply to

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

    Jan-Pieter

    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-2014 The ORM Foundation: A UK not-for-profit organisation -------------- Terms of Service