Literal column names in Query fixture

[Jeremy Simmons]

I have a result set with column names that differ only by a space.

Is there a switch or setting that will allow me to use literal names for my columns?

|Query|!-select 1 as PolicyNumber, '1-CO' as [Policy Number]-!|

|Policy Number|!-Policy Number-!|

|1            |1-CO|

Results

1 missing 1-CO

1-CO surplus 1-CO

My issue seems to be coming from the binding that RowSetFixture is doing.

https://github.com/dbfit/dbfit/blob/master/dbfit-java/core/src/main/java/dbfit/fixture/RowSetFixture.java#L74

int idx = findColumn(name);

https://github.com/dbfit/dbfit/blob/master/dbfit-java/core/src/main/java/dbfit/fixture/RowSetFixture.java#L53

private int findColumn(String name) throws Exception {
//todo: implement non-key
String normalisedName = NameNormaliser.normaliseName(name);
for (int i = 0; i < dt.getColumns().size(); i++) {
String colName = dt.getColumns().get(i).getName();
if (normalisedName.equals(NameNormaliser.normaliseName(colName))) {
return i;
}
}
throw new Exception("Unknown column " + normalisedName);
}

Looks like I'm pretty screwed here unless there's a way to control the behavior of NameNormaliser... which there doesn't appear to be.

I was hoping for something like this

|set option|fixed length string parsing|true|

http://dbfit.github.io/dbfit/docs/reference.html

StackTrace:

java.lang.NumberFormatException: For input string: "1-CO"

at java.lang.NumberFormatException.forInputString(Unknown Source)

at java.lang.Integer.parseInt(Unknown Source)

at java.lang.Integer.parseInt(Unknown Source)

at fit.TypeAdapter$ClassIntegerAdapter.parse(TypeAdapter.java:209)

at dbfit.util.ParseHelper.parse(ParseHelper.java:71)

at dbfit.fixture.RowSetFixture$CurrentDataRowTypeAdapter.parse(RowSetFixture.java:49)

at dbfit.fixture.RowSetFixture.findMatchingRow(RowSetFixture.java:123)

at dbfit.fixture.RowSetFixture.doRow(RowSetFixture.java:107)

at fit.Fixture.doRows(Fixture.java:162)

at fit.ColumnFixture.doRows(ColumnFixture.java:19)

at dbfit.fixture.RowSetFixture.doRows(RowSetFixture.java:93)

at fit.Fixture.doTable(Fixture.java:156)

at fitlibrary.traverse.AlienTraverseHandler.doTable(AlienTraverseHandler.java:21)

at fitlibrary.traverse.workflow.DoTraverseInterpreter.interpretWholeTable(DoTraverseInterpreter.java:104)

at fitlibrary.traverse.workflow.DoTraverseInterpreter.interpretWholeTable(DoTraverseInterpreter.java:89)

at fitlibrary.DoFixture.interpretWholeTable(DoFixture.java:73)

at fitlibrary.suite.InFlowPageRunner.run(InFlowPageRunner.java:27)

at fitlibrary.DoFixture.interpretTables(DoFixture.java:42)

at dbfit.DatabaseTest.interpretTables(DatabaseTest.java:26)

at fit.Fixture.doTables(Fixture.java:81)

at fit.FitServer.process(FitServer.java:81)

at fit.FitServer.run(FitServer.java:56)

at fit.FitServer.main(FitServer.java:41)

[Mark Matten]

As you say, it looks you're pretty screwed :(

You could obviously put a view over the table and use that as the interface to the table. It's not ideal. 

I'm not entirely sure why the name is normalised rather than just let badly specified names cause failures. 

I think an enhancement, either to remove the normalisation, or to control it via a new option (Set Option), are definitely required. 

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "dbfit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dbfit+un...@googlegroups.com.
To post to this group, send email to db...@googlegroups.com.
Visit this group at https://groups.google.com/group/dbfit.
For more options, visit https://groups.google.com/d/optout.

[Jeremy Simmons]

Mark - 

Thanks for your comment. Always nice to receive confirmation you've researched appropriately and find you're painted into a corner.

I cannot put a view over anything at this point, because I'm inspecting the result set of a stored procedure.

It's not possible to define a view over a stored procedure.

The name of the column in the Query fixture is normalised because of it's a fitnesse convention/idiom to do so. 

The fitnesse framework makes the assumption it should cater to the business analyst writing the test, instead of the more technical role of developer.

I'm going to work on a pull request to allow for a SetOption on the active DatabaseEnvironment to control the parsing.

My gut is to have three levels.

1. Current (fitnesse normalization (case insensitive with whitespace removed)

2. Explicit Case Insensitive

3. Explicit Case Sensitive (for the truly hedonistic)

One of my peers asked if you could specify columns by ordinal position.

I figure while I'm in there, I will add an option for finding result set columns by ordinal when the column name is specified as completely numeric (all characters are digits).

Cheers and thanks.

[Mark Matten]

Hi Jeremy,

I guess we should move this discussion to a GitHub issue/pull request.

I guess a work around could then be to create a stub/façade stored procedure with different parameter names and use this as the interface for testing it with DbFit.

The name normalisation is actually a DbFit function rather than FitNesse. See

https://github.com/dbfit/dbfit/blob/master/dbfit-java/core/src/main/java/dbfit/util/NameNormaliser.java

For your pull request I think you could start with a simple true | false option (I.e. apply the current normalisation or not) and make sure there are acceptance tests to check that it doesn't break the column name to fixture column matching.

Mark

[erin larsen]

Hello, 

Our team has run into this as well after upgrading to the latest DBFit.  Is there a work around for this?  Also, we encountered another problem around NVARCHAR(MAX).  Is this also not supported anymore?

[Yavor Nikolov]

Hi Erin,

What kind of database are you using, did it work with previous versions of DbFit?

A possible workaround is what Mark suggested: create a wrapper in which you expose cleaner names of your parameters/columns.

Also you may reflect on the feedback this issue is providing to you. Is it a good design to have parameters differing only in white space? Can you do something about it?

Regarding NVARCHAR(MAX) - support hasn't been removed intentionally. Could you please file an issue at https://github.com/dbfit/dbfit/issues and provide more details about the problem.

Best Regards,

Yavor

To unsubscribe from this group and stop receiving emails from it, send an email to dbfit+unsubscribe@googlegroups.com.