Ayende @ Rahien

Adam Langley commented on On the sad state of NHibernate code generation

Thu, 29 Mar 2007 03:03:52 GMT

Frans, actually the whole model doesnt need to be placed on a single canvas, that was one of the features I put at the top of the list when I designed the NHibernate Addin. You can create multiple diagrams in a single project, and tables will be 'referenced' from one diagram to another automatically. Or, if you have referenced another project or assembly that contains a diagram, the plugin attempts to link to those types instead of recreating them in the new diagram. I personally hate not being able to divide your diagrams by domain (or purely for designer rendering performance), but have them act as one unified model... Thats what you're talking about isnt it?

Alessandro Riolo commented on On the sad state of NHibernate code generation

Tue, 20 Mar 2007 17:45:44 GMT

I just wrote a post about a good reason why LLBLGen Pro should start to support NHibernate (and ActiveRecord and Gentle.Net) code generation: http://ale.riolo.co.uk/2007/03/llblgen-pro-to-support-nh-gn-ar-1.html

Ayende Rahien commented on On the sad state of NHibernate code generation

Mon, 19 Mar 2007 08:50:55 GMT

Frans, I would make the argument that if you have several hundred entities, they should be broken to discrete modules, not used all at once. - Customers - Orders - Storage - Etc,

Frans Bouma commented on On the sad state of NHibernate code generation

Mon, 19 Mar 2007 08:11:15 GMT

That add-in makes the same mistake as the Linq to Sql/Entities designers: the whole model has to be placed on a single canvas. You can't do that with a model with several hundred entities.

Steve commented on On the sad state of NHibernate code generation

Sun, 18 Mar 2007 18:51:21 GMT

http://sourceforge.net/projects/nhibernateaddin Interesting... worth a look

Ayende Rahien commented on On the sad state of NHibernate code generation

Sun, 18 Mar 2007 11:03:48 GMT

The QWTWQ table name? That is from a DB2 database. I am sad to say that this isn't the worse that I have seen.

Frans Bouma commented on On the sad state of NHibernate code generation

Sun, 18 Mar 2007 10:53:17 GMT

Heh :) I agree that everyone should 'just do it right', however that's not the case in general, there are large groups of people who simply have to work with garbage stuff or create the garbage. If you want solid tooling which appeals to a lot of people, you unfortunately have to consider things like tablenames/fieldnames in other languages than english. And for example on DB2, people are often using abbreviations because of the tablename length limit which existed for a long time. In English it's also not 100% standarized though. There are plural names which can't be singularized using a simple routine. Perhaps these can be pulled from a table, I'm not sure.

Ayende Rahien commented on On the sad state of NHibernate code generation

Sat, 17 Mar 2007 23:28:38 GMT

> Singularization is language dependent. I _really_ don't want to get into this. And I mean _really_ not. I have to work with databases where the tables are called QWTWQ and there is a look up table somewhere that translate this value to Hebrew table name. And I have to work with databases where they transcript-ed from Hebrew. In both cases, it is a mess, annoying and plain obfuscated. I am not sure if it is because Hebrew is not using the Latin alphabet (btw, alphabet is a Hebrew term, for what it worth), but I consider code to be a WTF just by the nature it exists. > This makes it very complicated. Yes, all I want is to support English. I would explicitly not want support for Hebrew. if(lang == "he-IL") throw new NotSupportedException("Learn English - תלמד אנגלית");

Frans Bouma commented on On the sad state of NHibernate code generation

Sat, 17 Mar 2007 23:01:41 GMT

Singularization is language dependent. In dutch other rules apply and I'm sure in Hebrew other rules apply. This makes it very complicated. Template creation is actually not that exiting. A template editor is enough, we have one of course. The thing what's more important IMHO is the templates, and the framework to use these templates in, like a task based engine and task performer assemblies which perform the tasks for you, so you can generate a lot of different classes at the same time. (like we have). Actually, what we sell is the license for the designer/code generator engine, so we probably will consider the NHibernate templates, as it will make our work more complete as we currently don't have POCO support.

Ayende Rahien commented on On the sad state of NHibernate code generation

Sat, 17 Mar 2007 21:31:05 GMT

Singularzing the table names: https://svn.castleproject.org/svn/castle/trunk/ActiveRecord/Castle.ActiveRecord/Framework/Internal/Inflector.cs I can understand the business reasons for not wanting to support NH as well. I actually am more interested in a tool to create those templates than the templates themselves. Consider this as a challenge to the NHibernate community. Thanks for offering.

Frans Bouma commented on On the sad state of NHibernate code generation

Sat, 17 Mar 2007 21:15:26 GMT

The thing with 'Singularizing the table names when creating an entity', there's a problem with consistency: it's not always to drop the 's' from the end. LLBLGen Pro's designer has a lot of features to make names obey a given guideline, be it your own or the MS one, with plugins you can modify the names or whatever you want. Some people have asked me in the past to produce nhibernate templates, and as all meta-data is available, I can generate mapping files with all info but also entity classes and other additional classes. The thing is that we're currently undecided if this is useful to us, as it might show we don't trust our own o/r core library. Though if you want me to create the templates for you, Ayende, drop me a note. :)

Steve commented on On the sad state of NHibernate code generation

Sat, 17 Mar 2007 19:50:15 GMT

Gokhan, that would be excellent.

Ayende Rahien commented on On the sad state of NHibernate code generation

Sat, 17 Mar 2007 19:19:13 GMT

Cleaning the source from [ActiveRecord] attributes isn't a hassle, although I assume that you can make a check in the code and basically generate it twice, right? Once with attributes, and then generate the HBM from that. And a second time without the attributes

Gokhan Altinoren commented on On the sad state of NHibernate code generation

Sat, 17 Mar 2007 19:13:49 GMT

If I implement the following, does that count? Since ActiveRecord generate hbm.xml, before outputting code in ActiveWriter I run generated code through AR in memory to get hbm.xml. I can write it out to a file. Classes will be there, only they are also decorated with AR attributes. If that doesn't count, I fell like I'm still close to generating what you want.