I think this succesfully makes maintenance easier for downstream users of attr_json, while also demonstrating success at prioritizing maintainability of attr_json itself - it hasn’t needed a whole lot of work on my end to keep working across Rails releases. (also grateful to the quality and stability of the rails attributes API originally created by sgrif). The last attr_json 1.x release actually supported (in same codebase) Rails 5.0 through Rails 7.0 (!), and attr_json 2.0 supports 6.0 through 7.0. I know that management of rails “plugin” dependencies can end up a nightmare, and I feel good about avoiding this with attr_json.Īttr_json was actually originally developed for Rails 4.2 (!!), and has kept working all the way to Rails 7. Generally, I try to really prioritize backwards compatibility and maintainability, doing my best to avoid anything that could provide backwards incompat between major releases, and trying to keep major releases infrequent. And it comes three and a half years after the 1.0 release. While the 2.0 release includes a few backwards incompats, it really should be an easy upgrade for most if not everyone. Slow cadence, stability and maintainability We get some aspects of a schema-less json-document-store, but embedded in postgres, without giving up rdbms features or ordinary ActiveRecord affordances. One use case where I think attr_json really excels is when using Rails Single-Table Inheritance, where different sub-classes may have different attributes.Īnd especially for a “content management system” type of use case, where on top of that single-table inheritance polymorphism, you can have complex hierarchical data structures, in an inheritance hierarchichy, where you don’t actually want or need the complexity of an actual normalized rdbms schema for the data that has both some polymorphism and some hetereogeneity. Some to compare are jsonb_accessor, store_attribute, and store_model. There are some other gems in this “space” of ActiveRecord attribute json serialization, with different fits for different use cases, created either before or after I created attr_json - but none provide quite this combination of features - or, I think, have architectures that make this combination feasible (I could be wrong!). # => will correctly return changes in terms of models themselves SELECT "transactions".* FROM "transactions" WHERE ("transactions"."payload" -> 'invoice_number' ILIKE '%123%')īasically performing a search for records in transactions table that have a key called invoice_number with value containing a string 123, within a JSON column payload.My_model.embedded_lang_and_val.lang = "de" Now with our search set on link_type_cont (cont being just one of Ransack available search predicates), if the user entered for example 123 in the search filed, it would generate a query like this: To achieve this we added the following ransacker to our Transaction modelĪrel::Nodes::InfixOperation.new('->', parent.table, 'invoice_number') In our case we needed to perform a search within transactions table and payload JSON column, looking for records containing a key called invoice_number. You can find more information on Arel here. The premise behind Ransack is to provide access to Arel predicate methods. We were alredy using Ransack for building search forms within the application, so we needed a way of telling Ransack to perform a search by given key in our JSON column. While working on a Ruby on Rails application that used PostgreSQL database to store data, we came a across an issue where we needed to implement a search by key within a JSON column. Starting with v9.2, PostgreSQL added native JSON support which enabled us to take advantage of some benefits that come with NoSQL database within a traditional relational database such as PostgreSQL. Using Ransack to search for a key in PostgreSQL JSON column
0 Comments
Leave a Reply. |