On Sep 5, 2012, at 12:50 PM, Chuck Hill < email@hidden> wrote:
I've used ERJGroupsSynchronizer with success and I'm very happy with it. But, what if the app that updates my database is not a WO application, but something done directly on the db? What's the common practice?
I don't know if there is a common practice, a lot depends on your exact situation. You could poll the database for updates periodically. Or manage object freshness so that you get updated objects when needed.
I have considered writing an article on this, and have commented before on similar things (probably 10 year ago).
I've built systems that use triggers to update tables that monitor what's happening on the database. In general, I use 2 tables:
Transaction TransactionTouch
plus, all objects in the database have a foreign key to the transaction table.
All participants in the DB, whether WO or not, have to create a new Transaction entity and attach the trans_id as a foreign key to each row added/updated.
Each table that needs to be monitored has insert/update/delete triggers that insert rows into the TransactionTouch table, which also has a foreign key to the transaction.
Now, you can have an app that periodically checks the Transaction table for new transactions. Since you already know the highest number you scanned last, it's a simple short query (select * from transaction where OID > 1234). NOTE: transaction is a reserved word in many databases.
For each transaction, you can check what records were "touched" by looking at the corresponding TransactionTouch records. These typically just have the table name and primary key stored (enough for you to create the EOGlobalID). You can then read in the record and recreate a snapshot if desired, and update the database context with the new snapshot.
Ken |