Added new long route constraint and updated the int route constraint to int

[phillip-haydon]

Fix for #1565 because @mat-mcloughlin was too slow.

Note:

If you have two constraints on the same URL for int and long then first in wins since the scoring will be the same. But there's no way for us to truly know which route to pick.

If the user puts in 1000 but wants it to hit the long route then it may pick the int route.

But we can't prevent this, and the user is stupid if they're making routes like this anyway.

[jchannon]

G/W/T to make @thecodejunkie happy 😄

[phillip-haydon]

If you look at the tests, they don't constitute G/W/T, so its pointless.

[jchannon]

Agree but I think he wants them regardless. In your tests I'd do //Given/When on the browser get and a //Then over the assert

[horsdal]

I'd put // Givenin the ctor, // When over the the this.browser.Get and // Then over the assert

[horsdal]

Apart from GWT nickpicking 👍

[khellang]

Added the new constraint to the wiki 😄

[khellang]

How is this a breaking change?

[phillip-haydon]

https://github.com/NancyFx/Nancy/pull/1569/files#diff-beb661f87d0a8be138928b34c1530c1fR8

Because of this, the 'int' constraint changed from long to int and a new 'long' constraint was added.

If anyone was using int expecting larger than Int32 values it will break for them.

[khellang]

👌

[drankard]

What is the reason for this "fix" ?

A lot of refactoring, checking, casting and/or double routing is needed now.

I don't agree in the statement that "the user is stupid"
Most NUMBER routes are resource identifiers living in a database, that span from small int to long, hence called NUMBER, why not add a boxing datatype (as jchannon suggest in #1565) or let it be up to the developer to do the casting. if really needed ?

Am i missing something ?

[phillip-haydon]

@drankard we could have added 'number' but then we have int and number, removing int we now have a major breaking change, and a higher barrier to entry when MVC supports int and long. jchannon also agreed with int/long approach further down. And while we could let the developer do the casting the request would be more expensive for them to execute the module definition rather than just deny the request up front.

The check for us is not expensive. Its potentially expensive for the module.