Documenting code, one commit at a time.
When working with databases, especially PostgreSQL, ensuring data integrity during the seeding process is crucial. A common pitfall involves SQL escaping issues, particularly when dealing with special characters within string values.
Initial attempts to populate a database often involve seed migrations. These migrations contain SQL statements to
When building a multi-tenant application with Laravel and PostgreSQL, handling data isolation is crucial. One effective approach is to use separate database schemas for each tenant. This provides a high level of isolation, ensuring that data from different tenants remains completely separate. Let's explore how this works in practice within the Reimpact platform.
This post details improvements to error handling within the Reimpact/platform project, focusing on delete operations and providing more specific and informative error messages.
Previously, the platform had a generic catch-all for delete errors. This made it difficult to distinguish between expected errors, such as foreign key violations, and unexpected errors, hindering debugging
Maintaining data accuracy across all tenants in a multi-tenant application can be challenging. This post explores how to correct an issue where global rates were inadvertently made tenant-specific in a Laravel application, impacting data integrity.
Originally, the rates table was intended to store global rates applicable to all tenants.
In the Reimpact/platform project, we encountered a tricky issue with queue deserialization in our multi-tenant environment. This post details the problem, our investigation, and the solution we implemented.
Our application uses a queue to generate reports. A GenerateReportJob is dispatched, serializing the GeneratedReport model.
When working with the Reimpact/platform project, we encountered an issue with large upload deletions that resulted in failures and an unhelpful JSON response. This post describes how we resolved the deletion failure and improved the user experience by displaying a Filament notification instead of a raw JSON page.
Deleting a large number of generated reports and calculated data
When developing multi-tenant applications with Laravel, managing database schema updates across tenants can be tricky. This post discusses how to address a common issue: ensuring that all tenant databases have the necessary schema changes after migrations.
In a multi-tenant Laravel application, each tenant typically has its own database schema.
The Reimpact platform is focused on streamlining various business processes. A recent enhancement focuses on providing users with more immediate feedback on long-running report generation tasks.
Previously, users initiating report generation had to manually check back later to see if the report was complete.
In multi-tenant applications, ensuring data isolation between tenants is paramount. We encountered an issue in our Reimpact/platform project where queue jobs and dashboard caching mechanisms weren't properly respecting the tenant context, leading to errors and potential data leakage.
Two key areas were affected:
The platform project is undergoing continuous improvement to enhance its notification system.
Initially, the notification system stored data in a simple text column. However, as the platform evolved, the need for richer, structured data within notifications became apparent. This required a transition to a more flexible data type.
