ActiveRecord vs. Ecto teine ​​osa

See on sarja “ActiveRecord vs. Ecto” teine ​​osa, kus Batman ja Batgirl võitlevad andmebaasidest päringute üle ning me võrdleme õunu ja apelsine.

Olles uurinud andmebaasiskeeme ja migratsiooni ActiveRecordis võrreldes Ecto esimese osaga, kirjeldab see postitus, kuidas nii ActiveRecord kui ka Ecto võimaldavad arendajatel andmebaasist päringuid teha ning kuidas ActiveRecord ja Ecto võrdlevad, kui käsitletakse samu nõudeid. Tee käigus saame teada ka Batgirli identiteedi 1989–2011.

Seemneandmed

Alustame! Selle seeria esimeses postituses määratletud andmebaasistruktuuri põhjal eeldage, et kasutajad ja arvetabelites on neile salvestatud järgmised andmed:

kasutajad

* ActiveRecordi loodud aken_väli on vaikimisi Ecto-s sisestatud insert_at.

arved

* ActiveRecordi loodud aken_väli on vaikimisi Ecto-s sisestatud insert_at.

Selle postituse kaudu tehtud päringud eeldavad, et ülaltoodud andmeid hoitakse andmebaasis, seega pidage seda lugedes seda teavet meeles.

Otsige üksust selle peamise võtme abil

Alustame andmebaasi kirje hankimisega selle peamise võtme abil.

ActiveRecord

irb (peamine): 001: 0> User.find (1) Kasutaja koormus (0,4 ms) VALI "kasutajad". * "kasutajatelt" KUS "kasutajad". "id" = 1 $ LIMIT 2 $ [["id", 1 ], ["LIMIT", 1]] => # 

Ekto

iex (3)> Repo.get (kasutaja, 1)
[silumine] QUERY OK source = "kasutajad" db = 5,2 ms dekodeerimine = 2,5 ms järjekord = 0,1 ms
VALI u0. "Id", u0. "Täisnimi", u0. "E-post", u0. "Sisestatud_aat", u0. "Uuendatud_at" kasutajatelt "U0, kus u0 (u0." Id "= 1 dollar) [1]
% Financex.Accounts.User {
  __meta__: # Ecto.Schema.Metadata <: laaditud, "kasutajad">,
  e-post: "bette@kane.test",
  täisnimi: "Bette Kane",
  id: 1,
  sisestatud_at: ~ N [2018-01-01 10: 01: 00.000000],
  arved: # Ecto.Association.NotLoaded ,
  värskendatud_at: ~ N [2018-01-01 10: 01: 00.000000]
}

Võrdlus

Mõlemad juhtumid on üsna sarnased. ActiveRecord tugineb kasutajamudeli klassi leidmismeetodile. See tähendab, et igal ActiveRecordi lasteklassil on selles oma leidmismeetod.

Ecto kasutab teistsugust lähenemisviisi, tuginedes kaardistamise kihi ja domeeni vahel vahendajana hoidla kontseptsioonile. Ecto kasutamisel pole kasutaja moodulil teadmisi, kuidas ennast leida. Selline vastutus on olemas Repo moodulis, mis suudab selle kaardistada andmete andmebaasi all, milleks meie puhul on Postgres.

SQL päringu enda võrdlemisel võime märgata mõnda erinevust:

  • ActiveRecord laadib kõik väljad (kasutajad. *), Ecto aga ainult skeemi määratluses loetletud väljad.
  • ActiveRecord sisaldab päringule LIMIT 1, Ecto aga mitte.

Kõigi üksuste toomine

Läheme sammu edasi ja laadime andmebaasist kõik kasutajad.

ActiveRecord

irb (peamine): 001: 0> User.all Kasutajakoormus (0,5ms) VALI "kasutajad". * FROM "kasutajad" LIMIT $ 1 [["LIMIT", 11]] => # , # , # , # ]>

Ekto

iex (4)> Repo.all (kasutaja)
[silumine] QUERY OK source = "kasutajad" db = 2,8 ms dekodeerimine = 0,2 ms järjekord = 0,2 ms
VALI u0. "Id", u0. "Täisnimi", u0. "E-post", u0. "Sisestatud_aat", u0. "Värskendatud_saade" kasutajatelt "AS u0 []
[
  % Financex.Accounts.User {
    __meta__: # Ecto.Schema.Metadata <: laaditud, "kasutajad">,
    e-post: "bette@kane.test",
    täisnimi: "Bette Kane",
    id: 1,
    sisestatud_at: ~ N [2018-01-01 10: 01: 00.000000],
    arved: # Ecto.Association.NotLoaded ,
    värskendatud_at: ~ N [2018-01-01 10: 01: 00.000000]
  },
  % Financex.Accounts.User {
    __meta__: # Ecto.Schema.Metadata <: laaditud, "kasutajad">,
    e-post: "barbara@gordon.test",
    täisnimi: "Barbara Gordon",
    id: 2,
    sisestatud_at: ~ N [2018-01-02 10: 02: 00.000000],
    arved: # Ecto.Association.NotLoaded ,
    värskendatud_at: ~ N [2018-01-02 10: 02: 00.000000]
  },
  % Financex.Accounts.User {
    __meta__: # Ecto.Schema.Metadata <: laaditud, "kasutajad">,
    e-post: "cassandra@cain.test",
    täisnimi: "Cassandra Cain",
    id: 3,
    sisestatud_at: ~ N [2018-01-03 10: 03: 00.000000],
    arved: # Ecto.Association.NotLoaded ,
    värskendatud_at: ~ N [2018-01-03 10: 03: 00.000000]
  },
  % Financex.Accounts.User {
    __meta__: # Ecto.Schema.Metadata <: laaditud, "kasutajad">,
    e-post: "stephanie@brown.test",
    täisnimi: "Stephanie Brown",
    id: 4,
    sisestatud_at: ~ N [2018-01-04 10: 04: 00.000000],
    arved: # Ecto.Association.NotLoaded ,
    värskendatud_at: ~ N [2018-01-04 10: 04: 00.000000]
  }
]

Võrdlus

See järgib täpselt sama mustrit nagu eelmine jaotis. ActiveRecord kasutab kõigi klasside meetodit ja Ecto tugineb kirjete laadimisel hoidla mustrile.

SQL päringutes on jällegi mõned erinevused:

Päring tingimustega

On väga ebatõenäoline, et peame kõik kirjed tabelist tooma. Üldine vajadus on tingimuste kasutamine tagastatud andmete filtreerimiseks.

Kasutagem seda näidet, et loetleda kõik arved, mis on veel tasumata (KUI tasutud_maks on tühine).

ActiveRecord

irb (peamine): 024: 0> Arve. kus (makstud_at: null) Arve koormus (18,2ms) VALI "arved". * "ARVEST" KUS "arved". "makstud_aat" KASUTAB MITTE LUBAKS 1 dollarit [["LIMIT" , 11]] => # , # ]>

Ekto

iex (19)> kus (Arve, [i], is_nil (i.paid_at)) |> Repo.all ()
[silumine] QUERY OK source = "arved" db = 20,2ms
SELECT i0. "Id", i0. "Makse_meetod", i0. "Makstud_at", i0. "Kasutaja_id", i0. "Sisestatud_at", i0. "Uuendatud_at" FROM "arvetest" AS i0 KUS (i0. "Makstud_at" IS) NULL) []
[
  % Financex.kontod.arve {
    __meta__: # Ecto.Schema.Metadata <: laaditud, "arved">,
    id: 3,
    sisestatud_at: ~ N [2018-01-04 08: 00: 00.000000],
    pay_at: null,
    maksemeetod: null,
    värskendatud_at: ~ N [2018-01-04 08: 00: 00.000000],
    kasutaja: # Ecto.Association.NotLoaded ,
    user_id: 3
  },
  % Financex.kontod.arve {
    __meta__: # Ecto.Schema.Metadata <: laaditud, "arved">,
    id: 4,
    sisestatud_at: ~ N [2018-01-04 08: 00: 00.000000],
    pay_at: null,
    maksemeetod: null,
    värskendatud_at: ~ N [2018-01-04 08: 00: 00.000000],
    kasutaja: # Ecto.Association.NotLoaded ,
    user_id: 4
  }
]

Võrdlus

Mõlemas näites kasutatakse märksõna, mis on ühendus SQL WHERE klausliga. Ehkki genereeritud SQL päringud on üsna sarnased, on mõlema tööriista sinna jõudmisel olulisi erinevusi.

ActiveRecord teisendab argumendi pay_at: nil makstud_at: IS NULL SQL-i väljavõtteks. Ecto abil samale väljundile jõudmiseks peavad arendajad oma kavatsusest täpsemalt aru andma, helistades is_nil ().

Veel üks erinevus, mida tuleb esile tuua, on funktsiooni "puhas" käitumine, kus Ecto. Ainuüksi kus funktsiooni helistades ei suhelda see andmebaasiga. Funktsiooni kus naasmine on Ecto.Query struktuur:

iex (20)> kus (Arve, [i], is_nil (i.paid_at))
# Ecto.Query 

Andmebaasi puututakse ainult siis, kui kutsutakse funktsioon Repo.all (), edastades argumendina struktuuri Ecto.Query. See lähenemisviis võimaldab päringu koostamist Ekto-s, mis on järgmise jaotise teema.

Päringu koostis

Üks andmebaasipäringute võimsamaid aspekte on kompositsioon. See kirjeldab päringut viisil, mis sisaldab rohkem kui ühte tingimust.

Kui loote töötlemata SQL-päringuid, tähendab see, et kasutate tõenäoliselt mingisugust liitmist. Kujutage ette, et teil on kaks tingimust:

  1. not_paid = 'paid_at EI OLE MITTE'
  2. paid_with_paypal = 'payment_method = "Paypal"'

Nende kahe tingimuse ühendamiseks töötlemata SQL-iga tähendab see, et peate need siduma, kasutades midagi sarnast:

VALI * ARVEST ARVEST, KUS # {not_paid} JA # {paid_with_paypal}

Õnneks on nii ActiveRecordil kui ka Ectol selleks lahendus.

ActiveRecord

irb (peamine): 003: 0> Arve. kus.ei (makstud_at: null). kus (makse_meetod: "Paypal") Arvekoormus (8,0ms) VALI "arved". * FROM "arvetest" KUS "arved". " paid_at "EI OLE MITTE MITTE JA" arved "." payment_method "= $ 1 LIMIT 2 $ [[" payment_method "," Paypal "], [" LIMIT ", 11]] => # ]>

Ekto

iex (6)> Arve |> kus ([i], mitte is_nil (i.paid_at)) |> kus ([i], i.payment_method == "Paypal") |> Repo.all ()
[silumine] QUERY OK source = "arved" db = 30,0 ms dekodeerimine = 0,6 ms järjekord = 0,2 ms
SELECT i0. "Id", i0. "Makse_meetod", i0. "Makstud_at", i0. "Kasutaja_id", i0. "Sisestatud_at", i0. "Uuendatud_aatja" FROM "arvetest" AS i0 KUS (EI (i0. "Makstud_at) "ON NULL)) JA (i0." Pay_method "= 'Paypal') []
[
  % Financex.kontod.arve {
    __meta__: # Ecto.Schema.Metadata <: laaditud, "arved">,
    id: 2,
    sisestatud_at: ~ N [2018-01-03 08: 00: 00.000000],
    paid_at: #DateTime <2018-02-01 08: 00: 00.000000Z>,
    makse_meetod: "Paypal",
    updated_at: ~ N [2018-01-03 08: 00: 00.000000],
    kasutaja: # Ecto.Association.NotLoaded ,
    user_id: 2
  }
]

Võrdlus

Mõlemad päringud vastavad ühele ja samale küsimusele: „Milliste arvete eest maksti ja millist Paypali kasutati?“.

Nagu juba arvata võis, pakub ActiveRecord päringu koostamiseks kokkuvõtlikumat viisi (selle näite jaoks), samas kui Ecto nõuab arendajatelt, et nad kulutaksid päringu kirjutamisele natuke rohkem. Nagu tavaliselt, pole Batgirl (orv, summutage üks Cassandra Kaini identiteediga) ega Activerecord nii palju.

Ärge laske end petta ülaltoodud Ecto päringu paljusõnalisusest ja näilisest keerukusest. Päris maailma keskkonnas kirjutatakse see päring ümber nii, et see näeks välja järgmine:

Arve
|> kus ([i], mitte is_nil (i.paid_at))
|> kus ([i], i.payment_method == "Paypal")
|> Repo.all ()

Selle nurga alt vaadatuna muudab funktsiooni "puhaste" aspektide kombinatsioon, kus see, mis ise andmebaasi toiminguid ei tee, koos toruhalduriga muutma Ecto päringu koostise tõeliselt puhtaks.

Tellimine

Tellimine on päringu oluline aspekt. See võimaldab arendajatel tagada, et antud päringu tulemus järgib täpsustatud tellimust.

ActiveRecord

irb (peamine): 002: 0> Arve.korraldus (loodud_aat:: desc) Arve laadimine (1,5ms) VALI "arved". * FAKTIDEST "arved" TELLIME "arvete" järgi. "loodud_AT" DESC LIMIT $ 1 [["LIMIT ", 11]] => # , # , # , # ]>

Ekto

iex (6)> order_by (arve, desc:: insert_at) |> Repo.all ()
[silumine] QUERY OK source = "arved" db = 19,8 ms
SELECT i0. "Id", i0. "Makse_meetod", i0. "Makstud_at", i0. "Kasutaja_id", i0. "Sisestatud_at", i0. "Värskendatud_saade" FROM "arvetest" AS i0 ORDER BY i0. "Sisestatud_at" DESC []
[
  % Financex.kontod.arve {
    __meta__: # Ecto.Schema.Metadata <: laaditud, "arved">,
    id: 3,
    sisestatud_at: ~ N [2018-01-04 08: 00: 00.000000],
    pay_at: null,
    maksemeetod: null,
    värskendatud_at: ~ N [2018-01-04 08: 00: 00.000000],
    kasutaja: # Ecto.Association.NotLoaded ,
    user_id: 3
  },
  % Financex.kontod.arve {
    __meta__: # Ecto.Schema.Metadata <: laaditud, "arved">,
    id: 4,
    sisestatud_at: ~ N [2018-01-04 08: 00: 00.000000],
    pay_at: null,
    maksemeetod: null,
    värskendatud_at: ~ N [2018-01-04 08: 00: 00.000000],
    kasutaja: # Ecto.Association.NotLoaded ,
    user_id: 4
  },
  % Financex.kontod.arve {
    __meta__: # Ecto.Schema.Metadata <: laaditud, "arved">,
    id: 2,
    sisestatud_at: ~ N [2018-01-03 08: 00: 00.000000],
    paid_at: #DateTime <2018-02-01 08: 00: 00.000000Z>,
    makse_meetod: "Paypal",
    updated_at: ~ N [2018-01-03 08: 00: 00.000000],
    kasutaja: # Ecto.Association.NotLoaded ,
    user_id: 2
  },
  % Financex.kontod.arve {
    __meta__: # Ecto.Schema.Metadata <: laaditud, "arved">,
    id: 1,
    sisestatud_at: ~ N [2018-01-02 08: 00: 00.000000],
    paid_at: #DateTime <2018-02-01 08: 00: 00.000000Z>,
    makse_meetod: "krediitkaart",
    värskendatud_at: ~ N [2018-01-02 08: 00: 00.000000],
    kasutaja: # Ecto.Association.NotLoaded ,
    user_id: 1
  }
]

Võrdlus

Päringule tellimuse lisamine toimub mõlemas tööriistas otse.

Ehkki Ecto näide kasutab esimese parameetrina Arvet, aktsepteerib funktsioon order_by ka Ecto.Query struktuure, mis võimaldab order_by funktsiooni kasutada kompositsioonides, näiteks:

Arve
|> kus ([i], mitte is_nil (i.paid_at))
|> kus ([i], i.payment_method == "Paypal")
|> tellimine_ (kirjeldus:: sisestatud_at)
|> Repo.all ()

Piiravad

Mis oleks piiranguteta andmebaas? Katastroof. Õnneks aitavad nii ActiveRecord kui ka Ecto tagastatud kirjete arvu piirata.

ActiveRecord

irb (peamine): 004: 0> Arve.limiit (2)
Arve koormus (0,2ms) VALI "arved". * FROM "arvetest" LIMIT 1 dollar [["LIMIT", 2]]
=> # , # ]>

Ekto

iex (22)> limiit (arve, 2) |> Repo.all ()
[silumine] QUERY OK source = "arved" db = 3,6 ms
SELECT i0. "Id", i0. "Makse_meetod", i0. "Makstud_at", i0. "Kasutaja_id", i0. "Sisestatud_at", i0. "Uuendatud_at" FROM "arvetest" AS i0 LIMIT 2 "
[
  % Financex.kontod.arve {
    __meta__: # Ecto.Schema.Metadata <: laaditud, "arved">,
    id: 1,
    sisestatud_at: ~ N [2018-01-02 08: 00: 00.000000],
    paid_at: #DateTime <2018-02-01 08: 00: 00.000000Z>,
    makse_meetod: "krediitkaart",
    värskendatud_at: ~ N [2018-01-02 08: 00: 00.000000],
    kasutaja: # Ecto.Association.NotLoaded ,
    user_id: 1
  },
  % Financex.kontod.arve {
    __meta__: # Ecto.Schema.Metadata <: laaditud, "arved">,
    id: 2,
    sisestatud_at: ~ N [2018-01-03 08: 00: 00.000000],
    paid_at: #DateTime <2018-02-01 08: 00: 00.000000Z>,
    makse_meetod: "Paypal",
    updated_at: ~ N [2018-01-03 08: 00: 00.000000],
    kasutaja: # Ecto.Association.NotLoaded ,
    user_id: 2
  }
]

Võrdlus

Nii ActiveRecord kui ka Ecto suudavad päringuga tagastatud kirjete arvu piirata.

Ecto limiit töötab sarnaselt tellimusele, sobides päringu kompositsioonide jaoks.

Ühingud

Assotsiatsioonide käsitlemisel on ActiveRecordil ja Ecto-l erinev lähenemisviis.

ActiveRecord

ActiveRecordis saate kasutada mis tahes mudelis määratletud seost, ilma et peaksite selles midagi erilist tegema, näiteks:

irb (peamine): 012: 0> user = User.find (2) User Load (0,3ms) SELECT "kasutajad". * "kasutajatest" WHERE "kasutajad". "id" = $ 1 LIMIT $ 2 [["id" , 2], ["LIMIT", 1]] => #  irb (peamine): 013: 0> kasutaja.arved Arve koormus (0,4ms) VALI" arved ". * FROM" arvetest "KUS" arved " . "user_id" = $ 1 LIMIT 2 $ [["user_id", 2], ["LIMIT", 11]] => # ] >

Ülaltoodud näide näitab, et kasutajaarvetele helistades saame kasutajaarvete loendi. Seda tehes esitas ActiveRecord automaatselt andmebaasile päringu ja laadis kasutajaga seotud arved. Ehkki selline lähenemine muudab asja lihtsamaks, tähendab see, et kirjutage vähem koodi või peate muretsema täiendavate sammude pärast, kuid probleemiks võib olla see, kui iterite mitme kasutaja üle ja tõmbate iga kasutaja jaoks arved. Seda probleemi nimetatakse N + 1 probleemiks.

ActiveRecordis soovitatakse „N + 1 probleemi” paranduseks kasutada katte meetodit:

irb (peamine): 022: 0> user = User.includes (: arvetes) .find (2) User Load (0,3ms) SELECT "users". * FROM "users" WHERE "users". "id" = $ 1 LIMIT $ 2 [["id", 2], ["LIMIT", 1]] Arve koormus (0,6ms) VALI "arved". * FROM "arvetest" KUS "arved". "User_id" = $ 1 [[user_id ", 2]] => #  irb (peamine): 023: 0> user.invoices => # ]>

Sel juhul laadib ActiveRecord kasutaja toomisega innukalt arvete seose (nagu nähtub kahest näidatud SQL-päringust).

Ekto

Nagu juba võisite tähele panna, ei meeldi Ecto tegelikult maagiale ega kaudsusele. See nõuab arendajatelt selget kavatsust.

Proovime sama lähenemisviisi, kui kasutame Ectoga kasutaja arvete kasutamist:

iex (7)> ​​kasutaja = Repo.get (kasutaja, 2)
[silumine] QUERY OK source = "kasutajad" db = 18,3 ms dekodeerimine = 0,6 ms
VALI u0. "Id", u0. "Täisnimi", u0. "E-post", u0. "Sisestatud_aat", u0. "Uuendatud_saade" FROM "kasutajatelt" AS u0 KUS (u0. "Id" = 1 dollar) [2]
% Financex.Accounts.User {
  __meta__: # Ecto.Schema.Metadata <: laaditud, "kasutajad">,
  e-post: "barbara@gordon.test",
  täisnimi: "Barbara Gordon",
  id: 2,
  sisestatud_at: ~ N [2018-01-02 10: 02: 00.000000],
  arved: # Ecto.Association.NotLoaded ,
  värskendatud_at: ~ N [2018-01-02 10: 02: 00.000000]
}
iex (8)> kasutaja.arved
# Ecto.Association.NotLoaded 

Tulemuseks on Ecto.Association.NotLoaded. Pole nii kasulik.

Arvetele juurdepääsu saamiseks peab arendaja Ecto-d kasutades sellest Ecto-d teadma:

iex (12)> kasutaja = eellaadimine (kasutaja,: arved) |> Repo.get (2)
[silumine] QUERY OK source = "kasutajad" db = 11,8 ms
VALI u0. "Id", u0. "Täisnimi", u0. "E-post", u0. "Sisestatud_aat", u0. "Uuendatud_saade" FROM "kasutajatelt" AS u0 KUS (u0. "Id" = 1 dollar) [2]
[silumine] QUERY OK source = "arved" db = 4,2 ms
SELECT i0. "Id", i0. "Makse_meetod", i0. "Makstud_at", i0. "Kasutaja_id", i0. "Sisestatud_at", i0. "Värskendatud_aatja, i0." Kasutaja_id "FROM" arvetelt "AS i0 KUS ( i0. "user_id" = $ 1) TELLIMUS i0. "user_id" [2]
% Financex.Accounts.User {
  __meta__: # Ecto.Schema.Metadata <: laaditud, "kasutajad">,
  e-post: "barbara@gordon.test",
  täisnimi: "Barbara Gordon",
  id: 2,
  sisestatud_at: ~ N [2018-01-02 10: 02: 00.000000],
  arved: [
    % Financex.kontod.arve {
      __meta__: # Ecto.Schema.Metadata <: laaditud, "arved">,
      id: 2,
      sisestatud_at: ~ N [2018-01-03 08: 00: 00.000000],
      paid_at: #DateTime <2018-02-01 08: 00: 00.000000Z>,
      makse_meetod: "Paypal",
      updated_at: ~ N [2018-01-03 08: 00: 00.000000],
      kasutaja: # Ecto.Association.NotLoaded ,
      user_id: 2
    }
  ],
  värskendatud_at: ~ N [2018-01-02 10: 02: 00.000000]
}

iex (15)> kasutajaarved
[
  % Financex.kontod.arve {
    __meta__: # Ecto.Schema.Metadata <: laaditud, "arved">,
    id: 2,
    sisestatud_at: ~ N [2018-01-03 08: 00: 00.000000],
    paid_at: #DateTime <2018-02-01 08: 00: 00.000000Z>,
    makse_meetod: "Paypal",
    updated_at: ~ N [2018-01-03 08: 00: 00.000000],
    kasutaja: # Ecto.Association.NotLoaded ,
    user_id: 2
  }
]

Sarnaselt ActiveRecordi komplektile sisaldab eellaadimine seotud arvete toomist, mis teeb need kasutajate arvetele helistamisel kättesaadavaks.

Võrdlus

Taaskord lõppeb lahing ActiveRecordi ja Ecto vahel teada-tuntud punktiga: selgitamisega. Mõlemad tööriistad võimaldavad arendajatel hõlpsasti assotsiatsioonidele juurde pääseda, kuid kuigi ActiveRecord muudab selle vähem sõnaliseks, võib selle tagajärjeks olla ootamatu käitumine. Ecto järgib WYSIWYG-tüüpi lähenemisviisi, mis teeb ainult seda, mida näha arendaja määratletud päringus.

Rails on tuntud vahemälupõhiste strateegiate kasutamise ja reklaamimise kaudu rakenduse kõigis erinevates kihtides. Üks näide on vahemällu salvestamise lähenemisviisi kasutamise kohta vene keeles, mis tugineb täielikult võluväeldusmehhanismi jaoks N + 1 probleemile.

Valideerimine

Enamik ActiveRecordis leiduvaid valideerimisi on saadaval ka Ekto-s. Siin on nimekiri tavalistest valideerimistest ja sellest, kuidas ActiveRecord ja Ecto neid määratlevad:

Pakkima

Seal see on: oluliste õunte ja apelsinide võrdlus.

ActiveRecord keskendub andmebaasipäringute hõlpsusele. Suur osa selle funktsioonidest on koondunud mudeliklassidele endile, mis ei nõua arendajatelt põhjalikku arusaamist andmebaasist ega selliste toimingute mõjust. ActiveRecord teeb vaikimisi vaikimisi palju asju. Ehkki see hõlbustab alustamist, muudab see kulisside taga toimuva mõistmise raskemaks ja see toimib ainult siis, kui järgite “ActiveRecordi viisi”.

Ecto seevastu nõuab selgitust, mille tulemuseks on rohkem sõnaline kood. Eeliseks on see, et kõik on tähelepanu keskpunktis, midagi pole kulisside taga ja saate ise oma teed täpsustada.

Mõlemal on oma külg, sõltuvalt teie vaatenurgast ja eelistustest. Nii et kui võrrelda õunu ja apelsine, jõuame selle parima võimaliku tehnika lõppu. Peaaegu unustasin teile öelda, et BatGirli koodnimi (1989–2001) oli…. Oracle. Kuid ärgem süvenegem sellesse.

Selle postituse on kirjutanud külalise autor Elvio Vicosa. Elvio on raamatu Phoenix for Rails Developers autor.

Algselt avaldati see blogis.appsignal.com 9. oktoobril 2018.