The Closure should be evaluated when the row value queried.

When the Data Generator handles an infinite border, it should be considered as a weak border, which may be exceeded.

Suggestion:

findWhere does not throw an exception if the list is empty. Instead, each public method from the row collection type (getters / setters) except the getRowCount method will throw the exception.

Further, a package private method like getSingleRow() might return an Optional and "replace" the getWhere-API. This method would throw an exception if more than one row is returned, return an absent value if no row is found.

Advantages:

• Almost same behaviour like SB Testing DB
• Combined the APIs getWhere/findWhere

The getSingleRow() method could be public as well if required...

Define a model for the ID handling and Refs.

The common classes should be part of the database project.

• TableRowModel
• ColumnBinding

"jetzt" is used for a pseudo now time. It is a fixed value and depends on the instantiation time.

The new name should show the side-effect, that it does not change within a test.

Suggestions:

• instantiationTime
• steadyNow
• uniformNow
• constantNow
• invariantNow

Add methods to delegate the DataSet features deleteRow and newRow to the DSL builder class.

It should be possible to gernerate the Fluent Builder API classes without the new Table Builder API classes.

DSL use:

   class ExtendedDemoGroovyDataSet extends PersonDatabaseBuilder
   {
      def extendsDataSet() { DemoGroovyDataSet } 

Internal Implementation:

 public void tables(Closure<?> table)
 {
    tables(this, table);
 }

 public void tables(PersonDatabaseBuilder delegate, Closure<?> table){
   DataSetIdentificator lastDataSet = DataSetRegistry.use(delegate);
   table.setDelegate(delegate);
   table.setResolveStrategy(Closure.DELEGATE_FIRST);
   table.call();
   DataSetRegistry.use(lastDataSet);
}

Generate a sample DSL row in the JavaDoc of each Table in the table DSL.

A more current DbUnit version should be used.

Remove Flags which are not needed from Enum.

The documentation for the usage of the STU database libraries should be improved.

Use Spring Data

The example for the TeamRepo, PersonRepo and JobRepo should use Spring Data instead of plain Spring JDBC.

Remove the Interface for the Person Service

Only use interfaces when there are more than one implementation.

Until now the method name of a foreign relation inside a generated reference class was created based on the foreign relation identifier only.
${foreignCol.relation.foreignName}
That could result in identical methodnames with identical signature, if multiple references of same type exist.

To avoid that problem the method (relation) name is now generated as tuple of foreign relation identifier and foreign relation identifier local name.
${foreignCol.relation.foreignName}_${foreignCol.relation.localName}

The fix works, but the "quality" of the created DSL is decreased.
QA.hasMembers(Mr.Tester) must now be referenced as QA.hasMembers_belongsTo(Mr.Tester).

The problem must be analysed and a better solution should be found.

findWhere

Returns a list, should return an empty list when no element is found.

getWhere

Returns a Optional object guava google API will be used

Actually, the table classes in the dsl package do not represent a table. They are a kind of table builder instead. The class name should express that..

Add JavaDoc comments to the builder model API. The comments should also contains some code examples.

The builder API to describe the database model, should have a better way to define the meta information e.g. ID handling:

Is:

     addColumn("id", DataType.BIGINT, Flags.AutoInvokeNextIdMethod, Flags.IdentifierColumn)

Should:

     TableBuilder professorTable = 
        table("professor")
              .column("id", DataType.BIGINT)
                 .identifierColumn()
                 .autoIdHandling()
              .column("title", DataType.VARCHAR)
            .end();

If a referenced column is not an ID column, its value should be evaluated lazy.

Remove all Associations from a DataSet. For this feature the Ref types should provide a method removeFromDataSet().

Add the SB internal Generator Tests to stu.

The generator should generate the model and a DSL API.
And the DSL API depends on the model classes.

Comment can the DSL API code be plain Java source?

Is there a Java API for Groovy use.

Rename the remote method to target in model builder API.

Use the Future API from the common module for the LazyValue feature.

When importing the STU projects in Eclipse, Groovy natures are added. There may be conflicts due to different Groovy compiler versions.

IS:

    .column("professor_id", DataType.BIGINT)
      .references(professoren)
        .local("geleitetVon")
        .remote("leitet")
          .min(1)
          .max(1

SHOULD:

    .column("professor_id", DataType.BIGINT)
      .references(professoren)

The name of the reference is in this case the name and some postfix(suffix) like "To" or "From".

Large letters in columns in the model does not the work the code in the adapter class is wrong.

Add a clear() method for each table in the DSL to remove all row data from the table. The clear method only removes the rows no magic is done.

The relations should be described as a builder.

Remove general "Object" return type in IScope, rename class as well. DslIdentifier could be part of type information T

Is:

     public interface IScope
     {

       Object getDataSet();

       String getDslIdentifier();

     }

Should (or similar):

     public interface IScope<T>
     {

       T getDataSet();

     }

Problem:
Both the new Table Builder and the "classic" DataSet must represent the same Scope type (DSL identifer / T).
The class (DSL identifier) of the DataSet is used to distinguish different DSL types. But as the base DataSet class is abstract, the dataset's getClass() method will not return the type of the abstract DataSet class.

The table parser should not be part of the generated code.

• callback method for each Row

There should be a special table class to represent associative tables. In the Model Builder, there should be a method associationTable() to add this kind of table.

Model code may look like:

    associationTable("besucht")
        .column("student_id", DataType.BIGINT)
          .references(studenten)
            .named("besucht")
            .multiplicities("1")
            .description("Gibt an, welche Lehrveranstaltungen ein Student besucht.")
        .column("lehrveranstaltung_id", DataType.BIGINT)
          .references(lehrveranstaltungen)
            .named("besuchtVon")
            .multiplicities("3..100")
            .description("Gibt an, welche Studenten eine Lehrveranstaltung besuchen.")
      .build();

Create a generator for STU Database Models, which generates a model from real database (e.g. via JDBC).

Allow to check the integrity of the used references in a data set. If a reference cannot be resolved, the check should fail.

Support for multiple identifier columns might be added.

Currently, multiple identifier columns must be combined to a single column.

Integrate a Groovy script interpreter, so that STU and the Table Builder API can be used without Groovy Compiler.

Is:

    return title(ref.getTitle());

Should (not exactly)

    RowBuilder row = ref.getBuilder(this);
    return title(row.getTitle());