And I reckon I’m going to move to 1.0 pretty quickly right after that.
I promised that stability was going to be a feature, and actually I think it allready is.
I’ve been using QG extensively in production over the last year (there’s three or four projects I’m currently involved with that are using it, and I know of quite a few others).
Some ‘known issues’ have popped up though.
If you know you’re way around the lib there’s always a way to work around it, but recently I’ve been able to tear myself away from the Haskell compiler (and, I must admit, ‘Dwarf Fortress’) for long enough to start adressing these issues in a more fundamental manner.
One breaking change, unfortunately, was neccesary :
As of yesterday, relations are no longer bidirectional.
This means that if you define (f.i.) a OneToMany relation between a ‘Parent’ class and a ‘Child’ class, a Parent instance will no longer be automatically generated if you ask the generator for a Child instance.
There is now a ManyToOne method for just this case.
Believe me, It simplifies matters. Not only in quickgenerate, but for quickgenerate users (i.e. the client code) aswell.
All kinds of circular misery is now easily avoided.
As it really didn’t take me that long to update a production project with about two thousands tests, where about a quarter of them relied on this feature, and it actually simplified a lot of the code, I do believe it is worth the change.
I don’t think it will affect too many users as I’m probably the only one generating entire domains with just the one generator.
You can still do that if you want to though, you only need a couple of extra lines of code now.
You can combine the OneToMany with a similar ManyToOne, infinite recursion will be avoided, and you get the same behaviour that was there before, including all the problems that come with it.
So, once again, for those of you that are impacted, I’m sorry, but it needed to be done.
Also on the list for the 0.5 release.
– better support for inheritance.
– better support for the generation of constructor parameters and the ability to choose between different constructors.
Both features are now available through the ‘StartingValue’ method but a more intuitive API would be desirable.
There’s also a request for backing field generation, but I’m still hoping I can pull this off without taking a dependency hit to an external library.
In the meantime I’ve added a QuickGenerate.NHibernate.Testing.Sample project to the solution, as it seems that this is what most people are using it for these days.
Any issues that pop up while you’re trying to do this, just send me a failing test/use-case (and/or patch) and I’ll definitely look into it.
It’s still quite a simple example.
I’m using sqlite to demonstrate possibilities and, well, sqlite is … limited.
Feel (very) free to get involved in this part of the code 
.
And if anybody feels like contributing an E.F./AutoMapper/LLBGen/Ditto/whatever example, please do.
The AutoMapper example is on my todo list as you might have gathered from a previous post.
Specific Generator requests are also, as always, still welcome.
F.i. a ‘ShortGenerator’ was added recently and someone suggested a generator based on Regex expressions.
But seeing as how I hate RegEx with a passion (*), I’m going to leave that one as an exercise for some of the more masochistic devs out there .
(*) : have a look at Parsec for a decent, and really, only slightly more verbose, alternative.
On a sidenote :
– Once I’ve reached the QG 1.0 milestone, I promise I will give QuickDotNetCheck some much needed love.
I’d really like to clean up all of the QG tests and replace them with QDNC tests, but, … small steps, …
