#30 Serious correctness issues in generated SQL


I'm using the generated SQL Server code from the Orienteering model (this version is revised from the one posted in a previous bug report) and there are numerous things that either don't run (incorrect SQL) or are just logical errors. Some of the things I've seen are:

* Value constraints are named the same on every instance of the value type (this is illegal in SQL Server),

* Role names sometimes get used, and sometimes not, in generating names of fields, with the result that foreign key constraints refer to fields that don't exist in the DDL,

* NOT NULL fields are declared as such, but not NULL fields, even though the default can be changed,

* Extenal uniqueness constraints are generated incorrectly. For example:

Entrant has exactly one GivenName
Team is a subclass of Entrant
Competitor is a subclass of Entrant
Competitor has exactly one FamilyName
(Entrant.GivenName, Competitor.FamilyName) is unique.

Because Competitor is absorbed into Entrant, the uniqueness
constraint can be declared as a Unique constraint (but see below),
however it's actually generated as a UC across *just* the FamilyName
field, which is quite wrong.

* Unique constraints across more than one column are generated
assuming the wrong semantics for nullable fields. SQL Server only
allows one instance of a NULL, not any number.

At least some of these errors are not just SQL Server issues, but logical errors in the absorption process.


  • Anonymous - 2007-04-23
  • Kevin M. Owen

    Kevin M. Owen - 2007-04-23
    • priority: 5 --> 7
  • Kevin M. Owen

    Kevin M. Owen - 2007-04-23

    Logged In: YES
    Originator: NO

    We are currently in the process of making several important changes both to the core tool and to the early stages of the generation process. The net result of these changes should be a significant improvement in the quality of the various "artifacts" (including SQL) that we generate. The results from these changes should start showing up over the next few months, and we will hopefully have everything to a stable point to publish a release with these changes around early June.

  • Anonymous - 2007-04-24

    Logged In: YES
    Originator: YES

    Ok, thanks Kevin. Can I ask that you choose at least one real use case around which to define acceptance tests, and actually do the acceptance testing? It doesn't seem possible that you've compiled or run all of the generated artifacts from previous releases... and if a thing hasn't been tested, it isn't cooked yet! Even a "basic functionality test" is better than nothing.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks