One of the best ways to speed up your application's performance is to create or optimize indexes in your database. On my current project, when we created our database on the AS/400 last week, the DBA noticed that there weren't any indexed created. I expected this and said I'd do some research on creating indexes with Hibernate. Thanks to Gavin, it turns out to be quite simple. Let's say you have an XDoclet tag on a column you want to index. Currently it is:
@hibernate.property column="username" not-null="true"
If you're using Hibernate's <schemaexport> task, you can add an index on this column to your mapping file and it'll create the index when creating the database. To add an index, it's as simple as changing the above XDoclet tag to:
@hibernate.property
@hibernate.column name="username" not-null="true" index="index_name"
Now the hard part comes. Which columns should you put indexes on? From what I've heard, it's the ones that you use in where clauses of your queries. I expect one or two per table is sufficient (??). One thing I'm not sure of is: should id columns contain an index?
In AppFuse, I use Struts' LookupDispatchAction to map submit buttons to methods in my Actions. It's caused quite a headache for i18n, but Jaap provided a workaround and now everything works fine. However, as I did the Spring MVC implementation this weekend, I didn't have to do any complicated "button value -> method name" mapping. Part of it was because I didn't need to, but also because I discovered that you can easily just check if the button's name was passed in. Explaining this with code is probably easier. Let's say you have three buttons on a page:
The HTML code for the above buttons is:
<input type="submit" name="save" value="Save" />
<input type="submit" name="delete" value="Delete" />
<input type="submit" name="cancel" value="Cancel" />
Using the name as your key, you can easily check in your Action/Controller/etc. to see which button was clicked:
if (request.getParameter("save") != null) {
// do something
}
The nice thing about this is that it doesn't care what value you put on your button - just what you name it. It seems like all frameworks should use something like this, rather than a single parameter name (i.e. "method") that requires JavaScript on a button to change the method invoked. About a month ago, Rick Hightower mentioned that he uses a ButtonNameDispatcher for Struts. Rick, if you're reading this - I'm ready for that bad boy!