Hibernate version:2.1.7

Mapping documents:Middlegen 2.1

Name and version of the database you are using:Firebird 1.5.1

Hi, I know this is a topic that has surfaced a few times - the 'singularisation' of table names, and also column renaming.
I think the current versions perform mostly ok with our system, although I think we have one table that Middlegen gives a 'singular' name to and it isn't quite right.

Anyway, we currently have 3 issues...

1) What concerns me is we have a table called 'collections' - a major/important entity in our system. Middlegen calls this 'Collection' which is (IMHO) not too dissimilar to java.util.Collection (ok, it's different, but I still don't like it). We also have table 'copies' which becomes 'Copy' - again a name I'm not fond of.
I have seen that a 'singular' and a 'plural' name can be specified in the mapping file(s), but as our data model is still evolving it doesn't seem practical to modify these manually if we keep updating/regenerating them.

2) Of more concern now is the renaming of columns we have in our database. It seems that we often have to open the java source files (for tables we're querying against) to find out what middlegen has renamed the column to. For example, column 'defaultlendingperiod_days' has become 'defaultlendingperiodDays'. Not so significant you'd think, but glancing at our data model printout, picking a column and writing a query almost inevitably fails because the column names start out wrong, thus slowing down development.
With 105 tables and 650+ columns in our model, this is quite a pain.

3) Another issue we have is with the disregard (in some places) to the name of a column. For example rows in Copies belong to Resources, and each resource has a Type. However, a particular copy can override this default by having an 'alternateType', i.e a fk directly to the Types table. When middlegen generates the code for the copies table, it calls the column (property) 'type' instead of 'alternateType', which definitely makes the query harder to read when we want to retrieve both the default 'type' and 'alternateType', whether the different properties are prefixed by an alias or not (I guess they'd have to be ;-) ).
However in another part of the database, we have a 'Users' table which has 4 fk relationships (eg gender, department, group, etc) to a 'Words' table. In this case the generated columns are called 'wordByGender', 'wordByDepartment', etc... Again it would be easier if Middlegen just used the names we'd already decided on. We have to examine the generated code to see how Middlegen has decided to call these properties, and how they're capitalised.


So in short, we want to be able to tell Middlegen to use column and table names as-is, so as not to confuse the developers already familiar with the data model, and reduce development time. If we want all our table and entity names to stay plural, we should be able to do so.

Any solution to these problems?
Thanks,
Phil
PS. Does middlegen call single rows of table 'people' something like 'person'? If so it would have to come with a dictionary... and if so, is it internationalisable?

The default naming module does a few basic checks with consideration for a few special conditions. Its not a natural language parser nor is it backed by a dictionary. It can be replaced (by the user) with a version that can do this, or nothing or ignore a conversion if the name is X. Up to you - use the Ant script to tell it the class to use.

Which class would I sub class? Could you point us to some documentation? It is too late for me to use this on my current project but it would be nice next time.

Check the Middlegen documentation (and the Hibernate wiki).
To start see:
http://boss.bekk.no/boss/middlegen/plugins/hibernate.html
See dbNameConverter argument.

The documentation is not always upto date. The code is open source so you can always read the source code.

Excellent, thanks David, this may be just what we need, will look into it (and thanks gikjl for asking what I was about to myself ;-) ).
This should save us some time (another reason for us to start using hibernate part-way through a project).

Cheers