In Ecto you deal with this situation by simply creating different changeset functions. You often end up with a mess of conditional validations, or you are forced to extract form objects that have set of common, and set of different validations. This can be undesirable, when you have different set of requirements for registration and then update. In each context where a model instance will be used and save would be performed, the validations will be run. In ActiveRecord, you put the validations into the class definition. There is a fundamendal difference in philosophy here, between Ecto and ActiveRecord. |> validate_length(:title, min: 1, max: 200) def changeset(model, params \\ :empty) do When we query database, we will get and array of %Post, map of changed fields (taken from params for example) and performs validations. These objects are mutable, provide access to data, changes, functions to manipulate the data, validations and callbacks.Įcto is not an ORM, but it looks like one on the surface. This means it converts data that sits in database tables into Ruby’s native objects, and the other way around. No objects, just dataĪctiveRecord is an ORM.
ActiveRecord does not support any NoSQL databases at this point, and probably never will. Yet it’s tailored specifically towards SQL. You can also use Sqlite and MSSQL.ĪctiveRecord, on the other hand, supports slightly larger number of SQL databases.
My personal opinion is that ActiveRecord model looks best naked, which may be in the form of: class User. never use callbacks - to avoid “callback hell”.never use validations in models - extract “form objects”, using Virtus.model and ActiveRecord::Validations or similar solution.Instead we use service objects/decorators/serializers etc. never put business logic into ActiveRecord models - methods that perform operations on models, calculate some results etc.To minimize the risk of failure, when developing reasonably large Rails applications, our brave team came up with many rules when dealing with ActiveRecord. This is, of course, until a critical mass is met, when it tends to fall apart pretty badly. on the other hand it’s also easy to use and straight to the point, which allows a programmer to build solutions faster. I consider ActiveRecord problematic in many ways, and often a reason for bad code, bugs, and performance bottlenecks. “Oh, it’s just like ActiveRecord” were my first thoughts.
The issues with ActiveRecordĪs a Ruby programmer, first glimpse on the Ecto may give us the feel of similarity. To help making decisions for ourselves, and you, my dear readers, I have put together this post describing Ecto, Elixir’s flagship library to talk to databases. On the other hand, there is plenty of reasons to choose Ruby/Rails over Elixir/Phoenix, so the choice has to be done carefully. I believe Elixir and it’s libraries allow us to solve client’s problems in similar fashion to Rails, yet it provides some advantages that Ruby does not. Our approach tries to be pragmatic, and we did use Java, C++ or even PHP in place of Ruby, where it was appropriate. We still love Ruby and Rails, but it’s been a bitter-sweet relationship for quite some time now. Generally, as a development company that specializes in solving difficult problems to our clients, we use best tool for the job approach. The issues we have, when using Ruby, are usually a result of limitations put on us by the language itself (performance, scaling, handling failures and recovery), but also architectural decisions made by libraries and framework’s authors. We used Elixir with client’s projects already, and the experience was generally positive. For about a year now, however, we have been looking at Elixir programming language and it’s ecosystem, to help us solve problems that Ruby (and Rails) fail to address. At AmberBit we still mostly develop Ruby on Rails applications for our clients.
0 kommentar(er)
