Skip to main content

    Filter by idea status

    Filter by product

    859 Ideas

    rory.smith
    TimeXtender Xpert
    rory.smithTimeXtender Xpert

    Automatic Impact-based change propagationSUBMITTED

    When you are applying changes in TimeXtender you often start at source-selection and then push changes forwards through DWH Data Areas into SSL. A common pattern to follow manually will then be:new field appears in a source table synchronize source (perhaps explicitly add the column to ODX) reload ODX synchronize objects add the field to DWH mapping in staging area (perhaps do some transformations on the field) map the field into subsequent Data Areas: MDW and perhaps other layers synchronize any downstream SSL edit the tables in downstream SSL to get the extra field thereWhat if TimeXtender could suggest a “push” of your changes downstream? In many cases you would want your new field to be made available downstream, and you now need to go through the manual steps listed above. Similarly to how the synchronization dialogues allow you to “help” TX by choosing mappings instead of manually performing them, you might be able to steer the generation of code and deployment and execution in one go from a simple interface dialogue. A similar functionality can be seen in coalesce.io where code changes can be propagated downstream.A more complex scenario can happen when you change a table that becomes a dimension to be historical (type 2):​​​​​​ you probably want to reevaluate surrogate keys (or introduce them) to properly couple your fact tables into the historical data you now have available. When I build in TimeXtender I set up history before dealing with facts so I can make use of the automated “you seem to be making a conditional lookup from a history table” function. In reality you are going to run into situations where you are making the change and then having some kind of “do you also want to change lookups in this way in your downstream” functionality would be really valuable. Especially because this would push implementations into “best practice” making for more consistency across implementations. This functionality would make applying changes faster and more controlled and would also foster more “end-to-end” thinking. 

    sierd.zuiderveld
    Contributor
    sierd.zuiderveldContributor

    Synchronize subset of tables in the source.SUBMITTED

    We have some datasources that have over 5000 tables. The can also have quite the amount of columns. Now when we synchronize the source, this can take up a few minutes.  I thought that, when we use “Select tables..”  that the synchronize would only query the tables within that those selection rules.  However we do not see this in the query on the database. Is this a feature or a 🐛 ? Here is the query SELECTt.[TABLE_SCHEMA],t.[TABLE_NAME],c.[COLUMN_NAME],c.[DATA_TYPE],c.[CHARACTER_MAXIMUM_LENGTH],c.[NUMERIC_PRECISION],c.[NUMERIC_SCALE],c.[DATETIME_PRECISION],c.[ORDINAL_POSITION],c.[IS_NULLABLE],prim.[CONSTRAINT_NAME] AS [PRIMARY_KEY_NAME],t.[TABLE_TYPE]FROM [INFORMATION_SCHEMA].[TABLES] tINNER JOIN [INFORMATION_SCHEMA].[COLUMNS] c ON t.[TABLE_CATALOG] = c.[TABLE_CATALOG] AND t.[TABLE_SCHEMA] = c.[TABLE_SCHEMA] AND t.[TABLE_NAME] = c.[TABLE_NAME]LEFT OUTER JOIN ( SELECT tc.[CONSTRAINT_NAME], tc.[CONSTRAINT_SCHEMA], tc.[CONSTRAINT_CATALOG], cc.[TABLE_NAME], cc.[COLUMN_NAME] FROM [INFORMATION_SCHEMA].[TABLE_CONSTRAINTS] tc INNER JOIN [INFORMATION_SCHEMA].[CONSTRAINT_COLUMN_USAGE] cc ON tc.[CONSTRAINT_NAME] = cc.[CONSTRAINT_NAME] AND tc.[CONSTRAINT_SCHEMA] = cc.[CONSTRAINT_SCHEMA] AND tc.[CONSTRAINT_CATALOG] = cc.[CONSTRAINT_CATALOG] AND tc.[TABLE_NAME] = cc.[TABLE_NAME] AND tc.[TABLE_CATALOG] = cc.[TABLE_CATALOG] AND tc.[TABLE_SCHEMA] = cc.[TABLE_SCHEMA] WHERE tc.[CONSTRAINT_TYPE] = 'PRIMARY KEY') primON t.[TABLE_CATALOG] = prim.[CONSTRAINT_CATALOG] AND t.[TABLE_SCHEMA] = prim.[CONSTRAINT_SCHEMA] AND t.[TABLE_NAME] = prim.[TABLE_NAME] AND c.[COLUMN_NAME] = prim.[COLUMN_NAME]ORDER BY t.[TABLE_SCHEMA], t.[TABLE_NAME], c.[ORDINAL_POSITION] 

    Email notifications using MFA accountsSUBMITTED

    Hey, in the documentation on executions/jobs I found the following information on setting up emails as notifications for succeeded and failed executions:Enter the information for the SMTP server you want to use under Mail Server. Since October 1st, 2022 Microsoft has ended basic authentication on email on online SMTP servers. To deal with this you need to add an Application (client) id for an app to use for this and the Tenant ID for your company. The app you use needs the following permissions.   You need the three options, (Mail.Send, SMTP.Send and User.Read) set on your app You need a Admin to grant consent for the three settings. The user account you add as the From Email and the User name needs to run without Multi-factor Authentication. If you use GMail to authenticate, it is not possible to use email and an std password. Here you need to turn on 2-step authentication for your email account and then use the App Password in the password field. My question:We have a policy that MFA is required for every account, and we do not want to make an exception for this.“The user account you add as the From Email and the User name needs to run without Multi-factor Authentication.”Are there any plans to support for example a client secret setup, to authenticate with the App registration using a client secret? For now this means we cannot use email notifcations, which prevents us from monitoring our TX environment. Kind regards,Rutger