0

How do a rename a domain class while reverse engineering or after reverse engineering.

i generated class using reverse engineering in Groovy and Grails.

the domain class name was AgentTable. I want to rename it as Agent. When i renamed the domain class using IntelliJ (right click - refactor - rename), it renamed the AgentTable to Agent whereever it was used. but when i start the server (run the app), giving error "nested exception is org.hibernate.HibernateException: Missing table: agent"

I have to do this for few domain class. is it anyway i can give an alternative name while reverse engineering the domain classes.

or after domain class was created how do i rename it without this error.

tim_yates
  • 167,322
  • 27
  • 342
  • 338
Siva
  • 11
  • 5
  • maybe there is a text string somewhere with that name that the rename missed? – Ray Tayek Apr 24 '17 at 19:27
  • what or how is you DB configured, I mean if you have it set not to create the table and it is using mysql or something then it hasn't created the table. You need to check what the db tables are and if it exists. If not then rename the table in mysql or whatever db too – V H Apr 24 '17 at 19:33

2 Answers2

2

Look into your database the name of the table it created for the agent. Once you know the name of the table add the following in your new domain

static mapping = {
    table "table-name-here"
}
elixir
  • 1,394
  • 1
  • 11
  • 21
  • hi i want to ask one more question.Does groovy and grails support SharePoint integration. we use SharePoint as our document management system. we need to retrieved few documents using Groovy and grails app and display to the user. – Siva Apr 26 '17 at 14:24
  • I am not sure about grails/Sharepoint integration. I am sure there must be some hooks/api provided by SharePoint to add/retrieve documents. If my answer worked, could you mark it as accepted answer? – elixir Apr 26 '17 at 15:30
  • i will check that out and let you know. – Siva Apr 26 '17 at 22:06
  • this link explain how to integrate . but doesn't have full infor https://support.avoka.com/kb/display/TKB/Transact+Manager+-+Sharepoint+Integration – Siva Apr 26 '17 at 22:23
0

While it works I would not recommend @elixir 's approach.

In my opinion the mapping is not supposed to be used for renames. This is also how I understand the official documentation.

In the example they use it to map Person onto the 'people' table, not because of a rename but because of a semantic reason. Tables are typically named after the plural form. Here is a nice answer on another question regarding this. In the project I am working on the domain object 'User' is mapped to the table 'users'. You can not use the table name 'user' as it is an SQL statement.

Assumptions and clarifications:

In my experience Grails maps the domain name to the table name after these rules (example domain name 'MyExampleDomain':

  • separate the domain name by capital letters (My Example Domain)

  • lower case all (my example domain)

  • replace spaces with underlines (my_example_domain)

Following this your Domain Class 'AgentTable' has a table 'agent_table' in your respective database. After your rename Grails even tells you what it wants:

nested exception is org.hibernate.HibernateException: Missing table: agent

It wants to look up values in a table called 'agent' but it can not find it. The refactor function of IntelliJ does not rename the functions, so it will miss out on the database.

Luckily we know exactly what values it wants - the values previously found in 'agent_table'.

So why create this confusion with remapping domains and table names when we could just rename the table and be done with it?

The solution:

Execute an SQL script like this on your database:

ALTER TABLE <old_domain_name> RENAME TO <new_domain_name>;

The names are of course in their "table-form".

This simply renames your table to match the expected format in Grails. When restarting everything should be fine.

However you do not need to use rename. You could also create a whole new table, build it the way the domain objects wants it to be and then migrate the data. See section 'Problems with this approach' for information on when to use what.

Problems with this approach:

As always, tinkering with information a program depends on (and even generated itself) will often have some dire consequences if you aren't careful.

For example we have to pay attention to keys. If your domain object has a relation to other objects it will hold them in the table via foreign keys. Depending on how you chose to migrate the information in the table you might have deleted these foreign keys connections. You will have to add them via a separate SQL statement. When you choose to recreate the table this will happen for sure. Renaming it should keep the keys.

Another one are column names. If you choose to rename attributes you will also have to rename the columns via SQL. You will also have to remember the foreign keys other tables might have on the table you are renaming. RENAME did this automatically for me, but you should double check.

Why you should still stick with this approach:

Remapping domain objects to the tables with old names is bound to create code smell and confusion. Do you really want to remember these mappings in your head? And more importantly: do you really expect other people to have to work with this?

The best case is if people can't even tell if this object has ever had a different name and changing the database is the best way I know to achieve this.

AK_is_curious
  • 239
  • 5
  • 13