{
"type": "FeatureCollection",
"features": [
{
"type": "Feature",
"id": 1,
"properties": {
# filename: single_page_rails_app.ru | |
# RUN via: `rackup single_page_rails_app.ru` | |
require "bundler/inline" | |
gemfile(true) do | |
source "https://rubygems.org" | |
gem "rack", "2.2.9" | |
gem "rails", "~> 7.1" |
# Example code to allow instances of the `User` model to have multiple `roles`: | |
# Migration ------------------- | |
class AddRolesToUsers < ActiveRecord::Migration[7.0] | |
def change | |
add_column :users, :roles, :text, array: true, default: [], null: false | |
end | |
end |
Ich schreibe mal runter, wie ich mir den Prozess vorstelle, ohne mir die SLOC API Docs anzuschauen:
- wir starten den
SyncSlocSensorsJob
- der nimmt sich alle Sensoren die in den letzten X Stunden nicht gesynct wurden
last_synced_at
- bei den am längsten nicht gesyncten anfangend, ruft er die SLOC API in Batches of 10 ab
- bei erfolgreicher Response
- wird
last_synced_at
in den 10 Sensoren updated nachdem
- wird
- die Werte in der DB gespeichert wurden
Is a Ruby gem to help separate concerns inside a Rails monolith.
https://github.com/Shopify/packwerk
Treat data modeling for packages like data modeling for network-isolated services:
hold foreign IDs referencing models across package boundaries, but do not hold strictly enforced foreign database keys and do not use ORM associations that would hide the separation of concerns.
Following the upper advise would be quite a change for our models. But less dependent: :destroy | :nullify | nil
decisions could actually make our lifes easier and our data more consistent (or just more fault tolerant). And not to forget that Packwerk allows to start small and increase its checks file by file.
I’ve found some confusing code in a project and would like to explain how and why I refactored it. As this is a small, very focused refactoring one can do in a "drive-by" manner while implementing another small change in this method, I think it serves well as an example.
The first thing that confused me was that our frontend is not sending the parameters we explicitly permit
in the route_event_params
method (see below), instead it is sending *_uuid
parameters...
And yes, this project unfortunately has
id
asprimary_key
and later addeduuid
which is the one known to the frontends.
UUID v4 UUIDs have the big drawback of being non-sortable. Fancy UUIDs encode the timestamp (just one digit short of microseconds) on the first bits and are therefore sortable.
They also encode a shortname of the generating model class, to make them globally identifiable.
Fancy UUIDs are just UUID v4 UUIDs - PostgreSQL and any other tool will be able to treat them like any other UUID v4 UUIDs.
Ok, I've refactored the service to not use the connection_pool
, but to use a new connection
instead.
And this also satisfies the rspec tests. I still don't understand what the issue was, but this is a working solution,
and as far as I see it also prevents us from blocking more and more connections, but instead closing them reliably.
This is the new code:
class ExecuteSqlService
class << self
To safely update the Ruby and Rails version, your app should have a proper test suite you can rely on. But even with a great test suite, I always recommend running a rake task, starting the rails console and starting the rails server and using your app in the browser, before opening a PR and asking for reviews.
Do it incrementally, don't skip any minor versions.
Which means, if your app is still on Ruby 2.7.x, then first update to the latest 2.7.X version, before updating to the latest 3.0.Y version and only when this has been done successfully, upgrade to the latest 3.1.Z version.