Posted by: Anonymous Coward
on November 12, 2006 12:26 PM
But that's the wrong approach. Integration based on PostgreSQL triggers means I need intimate knowledge of the database schema. If the database schema ever changes, my triggers might break or be inappropriate.
Well, in the long run, I think that both approaches have a great deal of merit in different areas.
The schema is going to change, and this can require changes to the triggers. However for some things that are simple and self-contained (notifying when a part becomes short), they work well. Also they are the only way to ensure that when data is changed in the db, you get real-time notification (what if the modification happens through another application that might be using shared stored procedures?). Also these are very good for areas where you *must* be sure that some change to information happened. For example, if Interchange and LedgerSMB (or SQL-Ledger) are running in different schemas in the same databases, triggers allow you to make sure that when an order is enterd in Interchange, it is definitely entered in LedgerSMB too (i.e. they both succeed or fail as a transaction). No other mechanism gives you this level of control.
The API is ideally when you need rough high-level ways of asking questions. I.e. you want Sugar to be able to list invoices on demand. In the end, it really depends on what you want to do which approach is best.
Long-range LedgerSMB will support both approaches.
Learn about Linux
Download Linux
Get Linux help
Re:More details on integration
Posted by: Anonymous Coward on November 12, 2006 12:26 PMWell, in the long run, I think that both approaches have a great deal of merit in different areas.
The schema is going to change, and this can require changes to the triggers. However for some things that are simple and self-contained (notifying when a part becomes short), they work well. Also they are the only way to ensure that when data is changed in the db, you get real-time notification (what if the modification happens through another application that might be using shared stored procedures?). Also these are very good for areas where you *must* be sure that some change to information happened. For example, if Interchange and LedgerSMB (or SQL-Ledger) are running in different schemas in the same databases, triggers allow you to make sure that when an order is enterd in Interchange, it is definitely entered in LedgerSMB too (i.e. they both succeed or fail as a transaction). No other mechanism gives you this level of control.
The API is ideally when you need rough high-level ways of asking questions. I.e. you want Sugar to be able to list invoices on demand. In the end, it really depends on what you want to do which approach is best.
Long-range LedgerSMB will support both approaches.
Best Wishes,
Chris Travers
#