refresh(int refreshMode): Refreshes the row's attributes with values from database. refreshMode should be a combination of REFRESH_.... See REFRESH_... constants for further information.
Sample:
EmpVOImpl eVO = getEmpVO();
EmpVORowImpl eRow = (EmpVORowImpl)eVO.getCurrentRow();
eRow.refresh(Row.REFRESH_UNDO_CHANGES|Row.REFRESH_WITH_DB_FORGET_CHANGES);
REFRESH_WITH_DB_FORGET_CHANGES forgets edits that the current user made to the row. The row data is refreshed from database. The latest data from database replaces data in the row regardless of
whether the row was modified or not.
If the current user had called ApplicationModule#postChanges() REFRESH_WITH_DB_FORGET_CHANGES will pick up the data that he himself wrote through his call to postChanges().
If REFRESH_REMOVE_NEW_ROWS is not specified, REFRESH_WITH_DB_FORGET_CHANGES puts a new row back to blank. If REFRESH_REMOVE_NEW_ROWS is specified, the new row is removed.
REFRESH_WITH_DB_ONLY_IF_UNCHANGED works just like REFRESH_WITH_DB_FORGET_CHANGES for unmodified rows, i.e., the row is refreshed with attribute values from the database. If a row was already modified by this transaction, the row is not refreshed.
If locking mode is pessimistic, the fact that you (this user) were able to change the data means that you were able to lock the row and that you got the latest data.
When using this refresh mode, if the locking mode is optimistic, the framework could bring the latest data for unmodified attributes and merge them into the row, while retaining changed attributes as is. However, this could lead to data integrity problems. Thus, for consistency sake and data integrity, we leave the row alone if it was modified even for optimistic locking mode.
If REFRESH_REMOVE_NEW_ROWS is not specified, calling refresh with this mode will be a no-op (treated just like a modified row). If REFRESH_REMOVE_NEW_ROWS is specified, the new row is removed.
REFRESH_UNDO_CHANGES works just like REFRESH_WITH_DB_FORGET_CHANGES for unmodified rows, i.e., the row is refreshed with attribute values from the database.
For a modified row, this mode refreshes the row with attribute values at the beginning of this transaction. This mode will back out changes that have been posted to database through postChanges(), but not yet committed. Suppose a row's attribute value was modified from 'A' to 'B' and 'B' is posted. Suppose further the user changes 'B' to 'C' (after the post). Calling refresh(int) with this mode will restore the attribute value to 'A'.
Out on database, the attribute value is still 'B'. However, the row is marked as modified, so that when the changes are posted later 'A' will replace 'B' out on database.
If REFRESH_REMOVE_NEW_ROWS is not specified, REFRESH_UNDO_CHANGES puts a new row back to blank. If REFRESH_REMOVE_NEW_ROWS is specified, the new is removed.
Sample:
EmpVOImpl eVO = getEmpVO();
EmpVORowImpl eRow = (EmpVORowImpl)eVO.getCurrentRow();
eRow.refresh(Row.REFRESH_UNDO_CHANGES|Row.REFRESH_WITH_DB_FORGET_CHANGES);
REFRESH_WITH_DB_FORGET_CHANGES forgets edits that the current user made to the row. The row data is refreshed from database. The latest data from database replaces data in the row regardless of
whether the row was modified or not.
If the current user had called ApplicationModule#postChanges() REFRESH_WITH_DB_FORGET_CHANGES will pick up the data that he himself wrote through his call to postChanges().
If REFRESH_REMOVE_NEW_ROWS is not specified, REFRESH_WITH_DB_FORGET_CHANGES puts a new row back to blank. If REFRESH_REMOVE_NEW_ROWS is specified, the new row is removed.
REFRESH_WITH_DB_ONLY_IF_UNCHANGED works just like REFRESH_WITH_DB_FORGET_CHANGES for unmodified rows, i.e., the row is refreshed with attribute values from the database. If a row was already modified by this transaction, the row is not refreshed.
If locking mode is pessimistic, the fact that you (this user) were able to change the data means that you were able to lock the row and that you got the latest data.
When using this refresh mode, if the locking mode is optimistic, the framework could bring the latest data for unmodified attributes and merge them into the row, while retaining changed attributes as is. However, this could lead to data integrity problems. Thus, for consistency sake and data integrity, we leave the row alone if it was modified even for optimistic locking mode.
If REFRESH_REMOVE_NEW_ROWS is not specified, calling refresh with this mode will be a no-op (treated just like a modified row). If REFRESH_REMOVE_NEW_ROWS is specified, the new row is removed.
REFRESH_UNDO_CHANGES works just like REFRESH_WITH_DB_FORGET_CHANGES for unmodified rows, i.e., the row is refreshed with attribute values from the database.
For a modified row, this mode refreshes the row with attribute values at the beginning of this transaction. This mode will back out changes that have been posted to database through postChanges(), but not yet committed. Suppose a row's attribute value was modified from 'A' to 'B' and 'B' is posted. Suppose further the user changes 'B' to 'C' (after the post). Calling refresh(int) with this mode will restore the attribute value to 'A'.
Out on database, the attribute value is still 'B'. However, the row is marked as modified, so that when the changes are posted later 'A' will replace 'B' out on database.
If REFRESH_REMOVE_NEW_ROWS is not specified, REFRESH_UNDO_CHANGES puts a new row back to blank. If REFRESH_REMOVE_NEW_ROWS is specified, the new is removed.
