RuleGen 3.0

Open architecture

The design goal for RuleGen 3.0 was to move towards a more open architecture. Previous releases (2.0 and 2.1) were closed products: code generation and deployment could only be performed from the Apex frontend, and all generated code was wrapped. Furthermore there was no distinction between design and runtime components. The framework had to be installed in full on all database environments (development, test, acceptance, production). With release 3.0 this has all changed.

  • There is now a clear separation of designtime and runtime functionality. Designtime is only required on the development environment. Test, acceptance and production environments only require a small runtime component.
  • All runtime component objects are delivered unwrapped. Also all code generated by RuleGen is now unwrapped.
  • The designtime is still wrapped pl/sql to protect our IP.
  • You can now transparently deploy the generated code by yourself. Release 3.0 offers an export functionality which will create a scriptfile that can be run from sqlplus.

Improved code generator

  • Release 3.0 no longer makes use of various OO features of the database. Though these were convenient within the closed architecture of the previous release, they did not benefit code readability, nor did they benefit the performance of the generated code.
  • The use of NDS (Native Dynamic SQL) in the code generated has been reduced: not only does this benefit the performance, but it also ensures that if code deployment went well (i.e. all objects are compiled and valid) then no unexpected runtime errors will occur. This also implies that dba_dependencies now gives a clear insight in the relation between all generated code objects.
  • Prior releases required that no open transactions be present on the database instance in order to be able to introduce a new rule. Release 3.0 relaxes this requirement to: no open transactions can be present on the tables that involve the new rule.

New features

Rule scoping

During testing it is often desirable to only have the rules enabled that are within the scope of the test. There are now two new RT service procedures that easily enable you to do this:

  • sp_rgr_set_rule_scope(p_rules in varchar2)
    This procedure accepts a comma-delimited list of rules. Calling this procedure will ensure that all rules except the ones in the list will be disabled (in your session).
  • sp_rgr_clear_rule_scope.
    This procedure undoes the effect of a previously set_rule_scope call in the session.

Rule validation

This feature enables you to check the full current contents of table with respect to a rule:

  • sp_rgr_validate_rule(p_rule in varchar2).
    This procedure will check the current content of all involved tables for the rule. Violation cases that are found will be stored in the RGR_RULE_VALIDATION_ERROR table in schema SYSRGRT30.


News & Events

Check out our new blog on triggers here.

Or follow us:

RuleGen 3.0 released

With the open architecture of release 3.0, RuleGen has set the path for the future. Improved code generation, transparent code deployment, and separation of design and runtime, are some of the key highlights of this new release.

Available now: AM4DP

Click to see book on Amazon

A great textbook about data integrity constraints in relational databases. This book describes the key concepts on which RuleGen is based. Click image to see reviews at Amazon, or here for quotes found on internet.