Support long Teradata object names

[MMatten]

• Add support for long table and column names in Teradata.
• Add new CoreTests test to test long names for all supported DB types.

resolves #400

[MMatten]

Long tables/column names are supported in Teradata from version 14.10.

Teradata Express is only available up to version 14 at the moment so we'll need assistance to test names between 31 and 128 characters.

[javornikolov]

Thanks @MMatten .
Looking at the travis output: here is the the dbfit build.

[MMatten]

Thanks. I'll need to ask the raiser of #400 to download this and test with Teradata 14.10+.

[MMatten]

The new CoreTests test it an attempt to add consistent structure to the tests even when the content has to vary by DBMS. I guess we could end up with lots of !define variables with this approach though.

[javornikolov]

The new CoreTests test it an attempt to add consistent structure to the tests even when the content has to vary by DBMS. I guess we could end up with lots of !define variables with this approach though

What about DB2, Derby, HSQLDB, MS SQL Server?

[MMatten]

What about DB2, Derby, HSQLDB, MS SQL Server?

Aha! I've forgotten to commit the symlink updates in the properties.xml files...

[MMatten]

Missing symlinks added for adaptors not using all of CoreTests.

Note that adapters that have a 128 char name length limit use the names from the !defines set in FitNesseRoot/DbFit/AcceptanceTests/content.txt.

[javornikolov]

I would vote for keeping the commas at the end of line.

[MMatten]

Ok for the fastbuild.

The pain is on the integrationBuild - when I uncomment ':dbfit-java:teradata:integrationTest' I have to remember to remove the comma from the end of ':dbfit-java:sqlserver:integrationTest' - always forget!

Ok to have different formatting/style?

[javornikolov]

Leading comma is a bit unnatural for people to read. Besides - I think we rarely commit changes to this list. If its some personal customization - it's perhaps better to keep customizations in separate (optional) non-version controlled file which to load if present (since it will be personal, anyone can use own style and formatting).

[MMatten]

Ok, I don't mind that.

Any ideas on how to extend the build customisation using another (non version controlled) file (or something like environment variables)?

[MMatten]

I've reverted the comma position in build.gradle and added an idea for your feedback please - using the user's gradle.properties to exclude integrationBuild tasks.

I've not bothered making this iterate over a list of DB type names/integration test tasks but just to show the basic idea.

What do you think?

[javornikolov]

Let's extract to a separate PR the configuration of excluded/included integration tests. (Seems a bit off-topic in the context of Teradata long names support). The rest looks OK to me.

[MMatten]

Good idea. It's getting too in depth for this PR.

Now removed from this one.