Modifying generated code

Blocks of code in the generated output are delimited by EGL comments that start with BEGIN and stop with END. For example: 
		/*
     * This function returns true if the supplied record is valid.
     * Customize to supply validation rules as needed.
     * isValid() is called prior to updating or inserting a row into the database.
     */
	//BEGIN IsValid
	// @generated - Delete generated tag to preserve modified code       
	Function IsValid(testRecord Employee) returns( boolean )
		return( true );
	end
	//END IsValid

You can modify the code between the BEGIN and END tags. However, be careful when customizing existing functions.

To preserve your modifications in case of transforming the UML model again, delete the comment line containing the @generated tag. Any code added outside the area delimited by the existing BEGIN and END tags is lost during the transformation. Adding BEGIN and END tags to modified code is not sufficient to guarantee its preservation.

Modification of existing function can cause the function to not work properly. If you modify a library function and the UML model or transformation parameters such that it changes what is produced by the transformation, you must also reconcile the modified code with the updated transformation output.

Additionally, you will need to consider the ramifications of the following changes:
  • Deleting code
  • Keys
  • User interfaces
  • Commit points
  • Paged search results

Considerations for cascading deletes

The generated delete functions do no cascade. To ensure that the functions meet your business needs, you will want to do the following:
  • Inspect the sample DDL and add any cascade instructions that are enforced by the DBMS.
  • Inspect the generated delete functions and add code to handle cascades as desired.
  • Because there is no generated cascade, users of the UI must ensure that deletions are not performed in a manner that would violate foreign key constraints. Attempts to perform a delete in violation of these restraints will fail.
  • Rows from associative tables produced by many to many Associations are not deleted when a row is deleted. Code must be added to produce this behavior in accordance with shop standards.

Considerations for database keys

Database keys are handled differently when transforming an existing database or a UML model.

  • When transforming from a UML model, transformation parameters can be added to class attributes to indicate whether or not the attribute represents a key column. Because there is no database connection when transforming a UML model, the value for the key column is not known. If key is not specified, a key column with the type of INTEGER will be inserted into the generated table definitions and corresponding SqlRecords. A key column is required.
  • When transforming from a database schema the key column will be created using the values of the database schema. If the database does not contain a key column no default is created. If a key is not specified, either in the table definition or through the wizard, the generated libraries will not function correctly. In this case, you will need to add code for the EGL data access functions to work correctly.

Considerations for user interface

You can specify database elements that are searchable and what data related to the element that is displayed in the results of a search as part of the transformation parameters. If you create interface pages that contain search and summary fields you will need to consider the following:
  • Search fields
    • You cannot specify large objects, such as BLOB and CLOB EGL types as searchable. If the database field attribute is a large object type, the Searchable attribute is ignored.
    • If no searchable parameter is specified, the key columns are made searchable.
  • Summary fields

    If nothing is specified to be included in the summary, the default is for all columns to be displayed in the search result summary.

Considerations for commit points

EGL commit points identify at what point during an operation data is saved to the database. The generated data access routines contain no explicit commit points. The general EGL behavior for implicit commit and rollback based on run unit is used. If your business needs are different from the default, you must add explicit commit points that meet your business needs.

Considerations for paged search results

Page control functions are included in the generated data access libraries. This allows the generated JSPs to page through search results in an efficient manner. If the target database management system (DBMS) does not support the following EGL statements, you will need to modify this function before using the List Page JSP:
  • OPEN <resultSet> SCROLL
  • GET ABSOLUTE
  • GET RELATIVE

Additionally, some DBMSs do not support the use of scrollable cursors on selects containing LONG VARCHAR or LOB columns. If this is the case, you will need to modify the paging function prior to using the List Page JSP.