I'm happy to see somebody saw the light...
http://fabiomaulo.blogspot.com/2008/12/light.html

Are you interested to make public part of the code (under LGPL) ?
We are specially interested in the part of hbm creation.
What we would do is create mappings before build the sessionFactory

At present I've not yet an idea on how to distribuite the product ( or portion of it ). It could be an LGPL project if I find some finances.

Felice, this is the most senseless idea about mapping helpers tool. You oblige the developer to write code…….
The graphical approach (like LINQ to SQL) allow easy and quick mapping.

Mike,
Thanks you for leaving your opinion.
The approach I show is a little different. Using the Linq To SQL graphics tool you need to design the database before, and then you drag your table in the design surface. You need to mantain your work in two places. With the textual DSL you write something very specific in a single point. You are right, I'm forcing the user to write code, but, at least, only once, and with a few lines I generate a lot of code in term of artifacts ( there is a big leverage effect). In addition, not all programmer likes graphical dsl ( me as well ). Is a matter of choice.

Hi to alls.
Mike: sorry but I disagree with you. This seems to be a nice and useful environment for mapping. The ‘graphical approach’ is another manner to work. They are incomparable.
Fellice: unfortunately this idea is not a lot original: try to googling a few and you will discover at least four analogous solutions (of course: GUI and pseudo-language are different).
Regards….

Frank,
Thank you for pointing the difference between a graphical approach and the textual one.
I did googled in the past, and found a lot of helper tools for nhibernate but the solution I propose is a little different. Most tool are in a certain way asymmetric: you start from one final point, and generate the others. The DSL approach centralize the mapping overall idea, and generates all the dirty stuff from an ideal ( or, at least, near to ) way of representing the model. In other words, even a non programmer can start to drop down some ideas and have a working program. I don't know if there is a unit for measure how a code generator is good: we can ideally think such a measure as a ratio from the countof keystroke instructing the generator by the resulting code equivalent count. If such a measure exist I think the solution I'm proposing will give a good performance.

Hi Felice,
I really like this idea. I've spent the last 2 years building similar graphical tools (DSL Tools for VS) for our own internal use and I'm now looking at oslo quite seriously. One thing that confuses me is your syntax for associations here, I'm not sure what this is supposed to convey, I would probably have gone for something like Authors: Author*. Just a suggestion.

Also, did you do the graph to model conversion manually or via XAML?

Thanks,
Pete

Hi Pete,
Actually the syntax you describe works too when the "right hand side" of the association is unique ( and actually is in the example ) so we could write Authors:Author* and Books:Book* with the same result. I decided to shown this syntax for completeness: you may have more than one end point on the same entity, and further you possibly would like to specify what is the "inverse " end point of the relationship.
I did the Graph visit manually. Don't know if it is the best way... I've a lot to learn on oslo too :)
I'm just asking the oslo team if it's ok for them, on placing NHModeller as open source, stay tuned :)