View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001167 | SymmetricDS | Bug | public | 2013-04-08 18:33 | 2023-05-16 18:05 |
| Reporter | rotten | Assigned To | elong | ||
| Priority | high | ||||
| Status | closed | Resolution | not fixable | ||
| Product Version | 3.3.4 | ||||
| Summary | 0001167: wild card triggers don't work in a forwarding environment | ||||
| Description | Our scenario: We have an application that is slowly being moved from using Database "A" to using Database "B". The application is being switched a few tables at a time. We use SymmetricDS to replicate all of the relevant tables from "A" to "B". (There is a lot of cruft in database "A", and we continually 'discover' new tables, so we have separate triggers for each table.) We have a data warehouse (C), which gets some of the tables used by the application. We send them from Database "B", using the 'sync_on_incoming_batch' to route changes from tables that are still mastered on Database "A". A --> B --> C Now, we want to configure database "D" as a hot standby for database "B": A --> B --> C | | V D It would get all of the tables in "B", not just the ones which are replicated to "C". We set up a wildcard trigger (*) with a route to "D". The unexpected result is the only tables which get routed to "D" are the ones that are NOT sent to "C" (nor routed back to "A"). Ie, ones that did not already have an explicit trigger. | ||||
| Steps To Reproduce | 1) Configure a set of nodes with a few tables in a schema. 2) Forward some of those tables along through one of the nodes. 3) Add a wildcard trigger on that middle node to capture all the tables to send them somewhere else. 4) Observe that only some of the tables are captured by the wildcard trigger. | ||||
| Additional Information | In our development environment we do not have the "C" database, so the lateral connection using a wildcard trigger to "D" worked well. Presumably the work around is to define explicit triggers and trigger_routers for every table destined to replicate to "D". We'll be trying that this week. -- A related, minor thing is if you already have a trigger on every table in a schema, and then configure a wildcard on that schema you will see this error in the logs: ERROR [TriggerRouterService] [qtp1280161282-14] Could not find any database tables matching 'myschema.*' in the datasource that is configured | ||||
| Tags | trigger | ||||
|
|
It is working as designed and documented. The most specific trigger, i.e. one with the exact table name, will override the more general trigger that matches on a wildcard. This can't be fixed without a redesign of how wildcards are meant to work and how trigger router service is structured. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-04-08 18:33 | rotten | New Issue | |
| 2014-02-13 15:19 | elong | Priority | normal => high |
| 2019-04-22 14:45 | elong | Tag Attached: trigger | |
| 2022-09-01 14:55 | emiller | Status | new => confirmed |
| 2023-05-16 18:05 | elong | Assigned To | => elong |
| 2023-05-16 18:05 | elong | Status | confirmed => closed |
| 2023-05-16 18:05 | elong | Resolution | open => not fixable |
| 2023-05-16 18:05 | elong | Note Added: 0002326 |