Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
Rails' Active Record callbacks provide a simple interface for executing a process when something happens to a database record. However, sometimes Active Record callbacks aren’t the best solution available. For those cases, this talk introduces a great alternative: Postgres' trigger functionality, a way of implementing callbacks at the database level. Coupled with Postgres' listen and notify features, you can develop creative solutions for making your Rails app the center of an otherwise complex system, managing data syncing and other processes seamlessly, regardless of consumers of the app.
Date
Summarized using AI?
If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.
Show "Summarized using AI" badge on summary page
Summary
Markdown supported
The video titled "Call me back, Postgres" features Ifat Ribon discussing the use of PostgreSQL's trigger functionality as an alternative to Rails' Active Record callbacks for managing data synchronization processes. ### Key Points Discussed: - **Introduction to Postgres Triggers**: The talk starts with an overview of PostgreSQL's native functionalities, particularly focusing on triggers and the listen/notify mechanism, which serves as a pub-sub system for database changes. - **Case Study Background**: Ifat shares her experience working on a project for a large international client using Salesforce, which required migrating data from a MySQL database to PostgreSQL. - **Integration with Salesforce**: The project involved using Heroku Connect as a data sync layer. It was found that existing legacy data in the PHP MySQL application couldn't leverage Active Record callbacks because the application made direct database commits. - **Approaches Explored**: - **Rails Callbacks**: Although they provide a user-friendly interface for syncing data, they proved ineffective since the legacy app operated outside the Rails API. - **Polling Scheme**: This approach involved running Cron jobs to query the database continuously, but was inefficient and potentially hazardous due to the need for manual coding and high expense. - **Postgres Triggers and Listen/Notify**: Ultimately, the triggers provide a means to listen for changes at the database level, which solved the issue of missing changes from users of other applications not routed through Rails. PostgreSQL triggers execute functions written in SQL triggered by data changes (insert, update, delete) and enable notifications that can be handled in Ruby. - **Implementation Details**: Ifat provides an overview of how to define PostgreSQL functions and triggers, explaining the nuances of writing SQL, the importance of maintaining database connections, and how to handle potential issues like continuous loops caused by trigger activations. - **Considerations for Data Syncing**: Several best practices are highlighted, including logging changes to ensure nothing is missed, maintaining separate connectivity for listeners, and ensuring the reliability of processes even amid connection interruptions. She emphasizes the importance of tests to verify attribute mapping and integration flows throughout the data sync process. ### Conclusion: The video concludes by stressing the utility of PostgreSQL's trigger functionality as a robust solution for implementing data synchronization without overly relying on Rails Active Record callbacks. This approach improves the flexibility and scalability of systems that require intricate data relationships across various applications.
Suggest modifications
Cancel
