That required storing all the translated values, and that’s a lot of overhead from the storage perspective.Īnother idea was to bring back immutability.
An improved version that stored raw values along with IDs also didn’t work out: surveys can have multiple translations, and we needed to show the responses in the current users’ locale. This approach was rejected almost immediately: it breaks the data integrity. The most naive and straightforward option is to store raw values instead of IDs. We considered different approaches to solve the problem. We are never sure that the answer we see now used to mean the same thing in the past. That makes historical data completely unreliable. So the answer with ID 1 and value “Very important” can easily change its value to “Not important at all” over time. In fact, when editing surveys, users prefer to completely change an already created answer instead of deleting the old one and creating a new one. They can be deleted or changed by survey creators. The problem is that the answers are not immutable. transform_values ! ( & :value ) # Extract values by IDs and form a string
RAILS POSTGRES JSON QUERY CODE
# approximate code module Surveys class Response answer.value} for managers to generate reports and analyze historical data.for managers to create questionnaires with different question types (single or multiple-choice, boolean, short answer, etc.).In the simplest terms, the feature allowed: The feature that brought Logidze back into my life was one of the most critical for the platform: the “Surveys”. The problemįor the last few months, Martians and me have been helping the core tech team of Retail Zipline, a retail communications platform, to enhance key features for their customers, build new functionality, improve the overall performance, and improve the developer experience. You know, the one you do for a living, not just because your love to write code. Now it’s time to talk about some real stuff. Logidze ❤️ F(x) Active Record time travel in the wild Now, if you have the fx gem installed in your project, Logidze generates functions and triggers using F(x) under the hood automatically. So I decided to integrate F(x) into Logidze, and it solved the main problem: no matter if you use schema.rb, or structure.sql, Logidze has got you covered! There are also activerecord-postgres_enum and Scenic to make PostgreSQL enums and views compatible with schema.rb, respectively. sql files and provides an API to “load” them into your Ruby migrations and the schema.rb. It is a Rails-only library that allows you to declare your SQL functions and triggers in separate. Well, it used to mean that.Įverything changed when I discovered a real gem- F(x). No triggers mean no fast model tracking and no Logidze. I’ve always seen opting for structure.sql instead of schema.rb as a necessary evil: yes, it’s not fun to resolve merge conflicts in SQL, and schema.rb is way more concise, but it does not support some PostgreSQL features like triggers, sequences, stored procedures or check constraints (only added in Rails 6.1).
RAILS POSTGRES JSON QUERY FULL
If you have never felt the need to use plain SQL format for schema or never saw in the wild: here’s the great post from AppSignal that explains everything about the two formats.Ĭheck out 1.0 release notes for the full list of changes. In the past, Logidze could only work with an SQL format for schemas, the structure.sql. The main feature of the latest release is the support for a default Rails way to store a database schema: the schema.rb. It helped me discover and cut all the rough edges, so keep reading to see what changed. I’ve been developing Logidze for almost half a decade, but only recently I was able to “dogfood” it properly inside a large Rails codebase.
If you want to know how this approach compares in speed to other popular Ruby gems like PaperTrail and Audited, check out my post where I introduce Logidze to the world back in 2016.
0 kommentar(er)
