This class does not contain the text of the underlying SQL statement. Rather, this class allows a code friendly way of referencing SQL statements. Since .sql files are simple text files, there is a need to build a bridge between these text files and java code. This class is that bridge.
Please see the package summary for important information regarding .sql files.
Typical use case :
public static final SqlId MEMBER_FETCH = new SqlId("MEMBER_FETCH");This corresponds to an entry in an .sql file :
MEMBER_FETCH { SELECT Id, Name, IsActive, DispositionFK FROM Member WHERE Id=? }
This class is unusual, since there is only one way to use these objects. That is, they must be declared as public static final fields in a public class. They should never be used as local objects in the body of a method. (This unusual restriction exists to allow the framework to find and examine such fields using reflection.) The text passed to the constructor must correspond to the identifier of some SQL statement block in an .sql file. Such identifiers must match a specific {@link #FORMAT}.
Startup Checks
To discover simple typographical errors as quickly as possible, the framework will run diagnostics upon startup : there must be an exact, one-to-one correspondence between the SQL statement identifiers defined in the .sql file(s), and the public static final SqlId fields declared by the application. Any mismatch will result in an error. (Running such diagnostics upon startup is highly advantageous, since the only alternative is discovery during actual use, upon the first execution of a particular operation.)
Where To Declare SqlId Fields
Where should SqlId fields be declared? The only real restriction is that they must be declared in a public class. With the most recommended first, one may declare SqlId fields in :
Design Note
The justification for recommending that SqlId fields appear in a {@link hirondelle.web4j.action.Action} is as follows :
|
|
|
|
|
|
|
|
|
|