compileInternal right way to go?

amy

I would like to create a subclass of MappingSqlQuery that I can reuse multiple times, but be able to change the SQL string each time.

This works if I call setSql(), compileInternal(), and execute() in this sequence, each time setting the new SQL query string.

I am not using parameter replacement because the SQL is too different each time, and it is much easier to create the dynamic SQL.

Is it proper to call compileInternal()?

It won't work with compile() alone because internally this sets a flag 'compiled' which prevents subsequent recompile. Is there a way to force compile() to recompile?

Why don't you just use the JdbcTemplate directly?  Just use an executeQuery method that takes a RowMapper as a parameter.

I think that MappingSqlQuery is a very good encapsulation of the functionality that I want. JdbcTemplate is quite complex and it is always cleaner to stick with simpler abstractions.

I have a suggestion:

If the setSql() method on the RdbmsOperation class would set the compiled  flag to false, as it should, then my usage would be fine and I wouldn't have to call any compile method at all.  The new SQL would be compiled the next time I call execute(). Is there any other state information to consider here?

Let me know if this makes sense.

MappingSqlQuery is meant to be a thraed safe object and your usage breaks that .  You might as well create a new MappingSqlQuery for each new sql and then throw it away when you are done. That makes more sense if someone else would look at your code.

It makes more sense to keep one instance of MappingSqlQuery per thread and reuse it in the way I described. Object creation and garbage collection can be expensive.  In what way are you providing thread safety here?

Well, that is not how MappingSqlQuery was meant to be used.  Once you start stretching the way an API was intended to be used, you quickly lose the benefit of the higher abstraction level.  That's why I suggested using the JdbcTemplate directly.  Also, I think that your database access and serialization/deserialization of the data returned from your query is far more expensive than creating a new MappinSqlQuery object when you have a new SQL statement.

I was having some issues with this class myself.  I was trying to call the setSQl statement and recompile within a method (so it should have been thread safe since all objects were local scope).  The code compiled correctly and it seemed to work other than I kept running the same SQL statement.  I looked up the documentation online and it didn't mention it being thread safe and that setSQL can't reset the SQL once it has been compiled.

I have read that java is even more efficient than C is instantiating new classes.
developerworks/ja...-jtp09275.html

So I wouldn't worry as that much about recreating the class.  Just a note in the documentation so us noobs aren't trying to do things it can't