support for unique properties

[ghost]

Following on from #22 I'm curious about why unique properties are unsupported? Presumably you could generate UUIDs for String properties and for numeric properties you could have a singleton instance of AtomicInteger and call getAndIncrement() on that every time a new value is required (performing a widening conversion to a float, double, etc. if required).

Of course if there are more values required for an integer property than there are available in the range Integer.MIN_VALUE..Integer.MAX_VALUE then you're stuffed, but this is a pretty unlikely case.

I guess I must be missing something, but what is it? If this sounds like a viable solution, I might give it a go myself.

[longwa]

I think that might work. For cases where the unique property had other constraints (like emails) you could still use the TestDataConfig.

If you can get it working, I'll test with our project to give you more coverage.

[tednaleid]

I think when I originally created the plugin, there were a few edge cases that I didn't want to deal with on unique fields and it was easier to punt on the whole thing and say BTD didn't support it. Looking at it again, I do think that it'd be pretty easy to get a 95% solution that can deal with:

• unique strings (with optional min/max length)
• unique email addresses (again with min/max length)
• unique numerics (with optional range constraint)
• unique credit cards
• unique urls

And mostly just punt (after a first try) on those uniques that also have a custom validator on them but be able to handle just about anything else.

@domurtag if you want to take a stab at it, go ahead, otherwise I'll probably look at implementing this in the next week or two.

[ghost]

I'll do my best to have a stab at this over the next week. I think if it we could get it working for 95% of cases that would be a significant improvement. The edge cases that are unsupported can fallback to using the config file.

[ghost]

BTW, how do I run the tests for this project? I guess it's not just a case of running grails-app from the nested build-test-data dir, because there seem to be other tests in `baseTests/test/integration'

[tednaleid]

Sounds good, thanks!

For testing everything, there's a bin directory at the root that has a testAll.sh script to run all the tests and a grailsAll.sh script to run an arbitrary grails command on every project (ex: bin/testAll.sh or bin/grailsAll.sh clean)