Uploaded image for project: 'Teiid'
  1. Teiid
  2. TEIID-3215

External Materialization ON_VDB_START_SCRIPT invocation issues

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 8.7.1, 8.9
    • 8.7
    • Server
    • Hide

      1. Define teiid_rel:ON_VDB_START_SCRIPT property with external materialized view table.
      2. Copy the vdb into deployments folder of stopped server
      3. Start the server
      4. Check that ON_VDB_START_SCRIPT wasn't invoked (Via debug log or expected action performed by the script)

      Show
      1. Define teiid_rel:ON_VDB_START_SCRIPT property with external materialized view table. 2. Copy the vdb into deployments folder of stopped server 3. Start the server 4. Check that ON_VDB_START_SCRIPT wasn't invoked (Via debug log or expected action performed by the script)
    • Documentation (Ref Guide, User Guide, etc.)
    • Workaround Exists
    • Hide

      Only deploy the VDB to the running server, not copy to the directory and start the server

      Show
      Only deploy the VDB to the running server, not copy to the directory and start the server
    • Low

      With materialized view I have set teiid_rel:ON_VDB_START_SCRIPT property for the external matview table. (Simple query to increment a column in table to count invocations.)
      Invocation of the script is dependent upon the way the vdb is deployed. The first case (A) doesn't invoke the script, the second (B) does.
      A - 1. Copy the vdbname-vdb.xml into deployments folder
      2. Start the server
      B - 1. Start the server
      2. Copy the vdbname-vdb.xml into deployments folder

      That means that after server stop (maintenance) the script is not invoked on start, which can cause problems when the script is used to initialize running environment (clear table, create temporary table,...)

            [TEIID-3215] External Materialization ON_VDB_START_SCRIPT invocation issues

            Van Halbert <vhalbert@redhat.com> changed the Status of bug 1309601 from NEW to CLOSED

            RH Bugzilla Integration added a comment - Van Halbert <vhalbert@redhat.com> changed the Status of bug 1309601 from NEW to CLOSED

            not an issue, per jstastny@redhat.com closing

            Ramesh Reddy added a comment - not an issue, per jstastny@redhat.com closing

            Jan Stastny added a comment -

            Not the same issue, I am sorry, I shouldn't have reopened this issue.

            Jan Stastny added a comment - Not the same issue, I am sorry, I shouldn't have reopened this issue.

            Jan Stastny added a comment -

            Reproduced the issue again with version 8.12.5

            Jan Stastny added a comment - Reproduced the issue again with version 8.12.5

            Filip Elias <felias@redhat.com> changed the Status of bug 1163685 from VERIFIED to CLOSED

            RH Bugzilla Integration added a comment - Filip Elias <felias@redhat.com> changed the Status of bug 1163685 from VERIFIED to CLOSED

            Jan Stastny <jstastny@redhat.com> changed the Status of bug 1163685 from ON_QA to VERIFIED

            RH Bugzilla Integration added a comment - Jan Stastny <jstastny@redhat.com> changed the Status of bug 1163685 from ON_QA to VERIFIED

            Van Halbert <vhalbert@redhat.com> changed the Status of bug 1163685 from MODIFIED to ON_QA

            RH Bugzilla Integration added a comment - Van Halbert <vhalbert@redhat.com> changed the Status of bug 1163685 from MODIFIED to ON_QA

            Jan Stastny added a comment -

            The attached vdb should demonstrate the issue. Below are schemas of required tables.

            CREATE TABLE check_table(
            id VARCHAR(50) PRIMARY KEY,
            vdb_create INT DEFAULT 0,
            vdb_drop INT DEFAULT 0,
            before_load INT DEFAULT 0,
            after_load INT DEFAULT 0
            )
            CREATE TABLE IF NOT EXISTS status(VDBName varchar(50) not null, VDBVersion integer not null, SchemaName varchar(50) not null, Name varchar(256) not null, TargetSchemaName varchar(50), TargetName varchar(256) not null, Valid boolean not null, LoadState varchar(25) not null, Cardinality long, Updated timestamp not null, LoadNumber long not null, PRIMARY KEY (VDBName, VDBVersion, SchemaName, Name));

            CREATE TABLE IF NOT EXISTS mat_view(customer_id INT NOT NULL,total_amount INT);ALTER TABLE mat_view ADD CONSTRAINT pk_customer_id PRIMARY KEY (customer_id);

            CREATE TABLE IF NOT EXISTS mat_view_stage(customer_id INT NOT NULL,total_amount INT);ALTER TABLE mat_view_stage ADD CONSTRAINT pk_customer_stage_id PRIMARY KEY (customer_id);

            Jan Stastny added a comment - The attached vdb should demonstrate the issue. Below are schemas of required tables. CREATE TABLE check_table( id VARCHAR(50) PRIMARY KEY, vdb_create INT DEFAULT 0, vdb_drop INT DEFAULT 0, before_load INT DEFAULT 0, after_load INT DEFAULT 0 ) CREATE TABLE IF NOT EXISTS status(VDBName varchar(50) not null, VDBVersion integer not null, SchemaName varchar(50) not null, Name varchar(256) not null, TargetSchemaName varchar(50), TargetName varchar(256) not null, Valid boolean not null, LoadState varchar(25) not null, Cardinality long, Updated timestamp not null, LoadNumber long not null, PRIMARY KEY (VDBName, VDBVersion, SchemaName, Name)); CREATE TABLE IF NOT EXISTS mat_view(customer_id INT NOT NULL,total_amount INT);ALTER TABLE mat_view ADD CONSTRAINT pk_customer_id PRIMARY KEY (customer_id); CREATE TABLE IF NOT EXISTS mat_view_stage(customer_id INT NOT NULL,total_amount INT);ALTER TABLE mat_view_stage ADD CONSTRAINT pk_customer_stage_id PRIMARY KEY (customer_id);

            Van Halbert <vhalbert@redhat.com> changed the Status of bug 1163685 from NEW to MODIFIED

            RH Bugzilla Integration added a comment - Van Halbert <vhalbert@redhat.com> changed the Status of bug 1163685 from NEW to MODIFIED

            The ON_VDB_START_SCRIPT will be executed when

            • vdb deploys
            • every time server restarts

            Recommendation to VDB developers is to make sure the script in written such a way that it accounts for server restarts. Like

            IF EXISTS ...
            

            examples http://stackoverflow.com/questions/1109061/insert-on-duplicate-update-in-postgresql/8702291#8702291

            Ramesh Reddy added a comment - The ON_VDB_START_SCRIPT will be executed when vdb deploys every time server restarts Recommendation to VDB developers is to make sure the script in written such a way that it accounts for server restarts. Like IF EXISTS ... examples http://stackoverflow.com/questions/1109061/insert-on-duplicate-update-in-postgresql/8702291#8702291

            please add your sample vdb and or testcase

            Ramesh Reddy added a comment - please add your sample vdb and or testcase

              rhn-engineering-rareddy Ramesh Reddy
              jstastny@redhat.com Jan Stastny
              Jan Stastny Jan Stastny
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: