Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Starting in etlunit 3.2.0, assertions have changed a bit in nature in order to make them work better and more consistently across both files and databases.

 

What's Changed

Prior to 3.2.0, the source file type drove the operation.  For example, in this assertion:

legacy assertions
assert(source-table: 'TABLE', target: 'MASTER');

The reference file type is the relational definition of the TABLE table, and the target file is opened using that definition.  Even if you specify file types for both the source and the target, the source is still the driver:

legacy-assert-full
assert(
	source-table: 'TABLE',
	source-reference-file-type: 'T',
	target: 'MASTER',
	target-reference-file-type: 'M'
);

 

In this case, since etlunit has been given enough information to interpret the file types on both sides, etlunit will use the source file type to extract data from the source table, and the target file type to open the local data file, then it intersects the source and the target to create an intersection of the two, and that becomes the basis of the assertion.  If columns are additionally specified, as in this, the column list is processed against the source, then intersected with the target.

legacy-assert-columns
assert(
	source-table: 'TABLE',
	source-reference-file-type: 'T',
	column-list-mode: 'exclude',
	column-list: ['ID'],
	target: 'MASTER',
	target-reference-file-type: 'M'
);

What happens here is that the source file type, 'T', is narrowed with the column list - specifically in this case the ID field is excluded, then the source data is extracted.  The target file type, 'M', is narrowed to match the source, then the target file is opened using that definition.  Any columns that don't match were silently ignored.

This same operation in 3.2.0 is processed like this:

  1. Open the target file type.
  2. Process the column list on the target file type.  This is the file type which drives the entire operation.
  3. Verify that the reference file type (the type created in (2)) is exactly a subset of the source file type.  If it isn't, an error is thrown.

 

The upside is that the local target file must exactly match the final definition of the target, not the original.  This entire process has changed in 3.2.0 - the target file must match the target reference file type exactly.

  • No labels

0 Comments

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account.