Customizing a Get Record transaction
Quite a lot of code is generated for a Get Record transaction, so it may appear complicated, but actually, this is the simplest way to implement a query against a new entity.
The generated code is executable without any customization. If you
deploy the code generated for the VehicleInfo model and add
some vehicle records, you can try running the
The default get transaction (
getXVehicle) is used to query records by
primary key and is not usually customized.
The generated implementation for the query
return all the records that exactly match the passed license number
value. It is fairly simple to customize this type of query if
required. You can freely modify the query SQL to anything you like,
without changing any other code, provided you observe the following
- The arguments must be kept the same in type and order, but you can change how they are used in the SQL.
- The columns in the result set are mapped into fields in the result object. Don't change the order or add or remove result columns. Provided the mapping to the result object isn't affected, you could derive the result column in a different way.
The most likely kind of customization is to change the
WHERE clause to
use the arguments differently. To do so, you need to edit the
InquiryData class for the entity that defines the Get
Record transaction. In this case, this is the class
XVehicleInquiryData in the VehicleInfo project. All the
InquiryData classes are generated into the .entityObject package.
Two SQL statements are generated for each Get Record transaction; you
can find them in static fields defined in the InquiryData class. For
XVehicleInquiryData, you should see:
Listing 11. Generated SQL
/** * <!-- begin-user-doc --> * <!-- end-user-doc --> * * @generated */ static final String getVehiclesByLicenseSql = "SELECT r.XVehiclepk_Id XVehiclepk_Id, r.license_Number license_Number, \ r.vehicle_Type vehicle_Type, r.owning_Party owning_Party, r.LAST_UPDATE_DT LAST_UPDATE_DT, \ r.LAST_UPDATE_USER LAST_UPDATE_USER, r.LAST_UPDATE_TX_ID LAST_UPDATE_TX_ID FROM XVEHICLE r WHERE r.license_Number = ? ";
There is also a similar field named
The History SQL is used for the query when inquireAsOfDate is included in the request header, in order to query the history records instead of the live records. If you don't need to support history queries, you can ignore it.
A very simple change to the
getVehiclesByLicense query will allow it to
support wildcards in the license number, which will make it more
Change the field
Listing 12. Customized SQL
/** * <!-- begin-user-doc --> * <!-- end-user-doc --> * * @generated NOT */ static final String getVehiclesByLicenseSql = "SELECT r.XVehiclepk_Id XVehiclepk_Id, r.license_Number license_Number, \ r.vehicle_Type vehicle_Type, r.owning_Party owning_Party, r.LAST_UPDATE_DT LAST_UPDATE_DT, \ r.LAST_UPDATE_USER LAST_UPDATE_USER, r.LAST_UPDATE_TX_ID LAST_UPDATE_TX_ID FROM XVEHICLE r WHERE r.license_Number LIKE ? ";
- In the
LIKE. This allows wildcards to be used in the argument. And in the comment above the field, change the
@generated NOT. This will preserve the change you have made when code is generated from the model again.
- Save the file.
- Now go back to the VehicleInfo model and generate code again.
This re-generates the
XVehicleInquiryDataImplclass from the
Each data class in the .entityObject package has a corresponding DataImpl class, which is the pureQuery-generated code that implements the SQL statements. Anytime you change the data interfaces, you need to make sure that the corresponding DataImpl class is re-generated. Running code generation from the model will do this.