Changing database column size using model-hints in Liferay

I had a task to modify Liferay’s core table column size, to make the column wider. Just to make it simple, the table that was going to be modified was User_ table ( User entity as the corresponding entity ), the column was emailAddress. I wanted to change the emailAddress column width to be 100. I was thinking “What are the options to do this, and what are the consequences?”.

So I found in Liferay’s Wiki this article. It explains you what is model-hints, and how you can use it to modify your table’s size column. To make it short, model-hints is a facility in Liferay to help ServiceBuilder to identify what is the column size and data type. This information is being used by ServiceBuilder to generate SQL script for the core portal, and for your entities ( if you use ServiceBuilder in ext environment to generate the entity ). It’s also needed to define the length of input form in your jsp file if you use liferay-ui taglib.

From the Wiki’s article, I found that to modify the column size is easy. Just re-define the entity and the column in ext-model-hints.xml, run the servicebuilder, and you’re good to go. So here is my modification to ext-model-hints.xml.

 	<model name="com.liferay.portal.model.User">
		<field name="emailAddress" type="String">
			<hint name="max-length">200</hint>
		</field>
	</model>

After that, I run ServiceBuilder. The service.xml that I used to run ServiceBuilder didn’t contain User entity definition. And after running the ServiceBuilder, I found out that the SQL script didn’t get modified by ServiceBuilder. So I tried to create a new service.xml, copy User entity definition from portal’s service.xml, and run ServiceBuilder. So what happened after that ? ServiceBuilder generated error…. hohoho…. I removed all the references in User’s service.xml, re-run ServiceBuilder, the error was gone. I checked the sql script ( portal-tables.sql ), the column size was changed as I expected.

So, was it done ? Not really. Because after I run ServiceBuilder for User entity, all the classes and interfaces were generated again in ext environment, along with hibernate mapping and Spring bean definition in ext-hbm.xml and ext-spring.xml. So what is the problem with that ? The problem is, I have to copy all User’s Impl classes and interfaces to ext environment, copy hibernate mapping from portal-hbm.xml to ext-hbm.xml. Another problem is with references from User entity to other entities.
So, from my point of view, this is not worth the effort. Unless you just want to change the display-width of your input field, then you just need to modify model-hints without having to redefine the entity in service.xml again.

So, what did I do to solve the problem ? I just redefine model-hints, and then changed the portal-tables.sql script manually. This portal-tables.sql script is a base script to generate database specific script located in ${your-ext-root}/sql/create and ${your-ext-root}/sql/create-minimal folder. After that, I went to ${your-ext-root}/sql, run the build-db ant target, so all the database specific script changed accordingly.

I think this solution is not really useful and take too much time. I prefer to use Liferay’s SQL script for the first time, do some modification (whether it’s column size or additional custom tables ), back up the script as template for production, rather than count on SQL script generated by ServiceBuilder. You would ask, why you choose that approach ? One reason I have in mind is, not all SQL script can be found in Liferay’s generated script. If you put Lucene’s index and JackRabbit’s repository in database rather than in filesystem, the SQL script generated for these are not found in Liferay’s generated script. That’s why I think it’s better to use Liferay’s generated script 1 time in the beginning, do modification, let Liferay create table definition for Lucene and JackRabbit repository, and back it up as SQL script for production system.

References :
forum question 1

« How to create portlet using Plugins-SDK and Eclipse

Bugs in ServiceBuilder »