Rails: портване на приложение от Postgres към SQLite (и не само)

1. Hai,

   Имаме Rails app (evans), чиито миграции са писани изключително за PostgreSQL. Какво можем да направим, за да фикснем съвместимостта с останалите DBMS-и?

   1. ОК ли е да редактираме миграции, ако редакциите включват промени само на ниво синтаксис на SQL?
   2. Тъй като повечето чупещи се миграции имат ефект върху базата данни, само когато в нея има някакви данни, можем ли да ги изпуснем при създаване на базата? (На всичкото отгоре промени по тях са трудни за тестване.)
   3. Има ли начин да „компресираме“ миграциите само до такива, които докарват базата до текущото ѝ състояние?

   И преди някой да е хейтнал, фен съм на Postgres, но не е яко да няма поддръжка за останалите DBMS-и защото:

   • Мързи ме да инсталирам и управлявам PostgreSQL сървър на машината си за разработка.
   • Не е ОК да не се възползваме от прекрасната абстракция на БД, която предлага Rails.
   • Кофти е да се пише нестандартен SQL, бил той и Postgre-complatible.

   Иии.. Как да изтестваме подобно начинание, освен с rake db:drop db:create db:migrate spec, change db, retry?

   P.S. Успях да преинача всички миграции до тази, която не ми ражда акъла как може да се напише на ANSI SQL, без да се разбие на няколко View-та.

   Публикувано преди над 11 години

2. Първо, като си говорим за evans, аз не искам да оправяме тази съвместимост. Като цяло, имаш решение дали да си съвместим с ANSI SQL или да се възползваш от базата, която имаш. Аз съм решил второто. Имам контрол над това, къде evans ще се качва и искам да се възползвам от определени функционалности на PostgreSQL. Също така, evans ми е (донякъде) място за експерименти и това е един от експериментите, които съм решил да направя.

   Накратко, не барай evans.

   Какво можеш да направиш – зависи от несъвместимостите. В общия случай, ако се ползва ActiveRecord и не се избива в специфичен SQL - приложението трябва да си работи директно.

   Ако си говорим как да промениш evans по принцип – зависи как можеш да направиш това, което аз правя с PointsBreakdown. Нямам никакъва идея, понеже не можеш да направиш view през абстракцията на Rails. Или намираш такъв начин и променяш кода или намираш друг начин да решиш проблема и променяш кода.

   Миграциите могат да се компресират и променят, но това трябва да се прави по изключение. Миграцията от една DBMS към друга е изключение, така че можеш да направиш каквото искаш с тях.

   Сега, не съм съгласен с трите ти bullet item-а.

   • Не трябва да те мързи да подкараш postgresql на машината си. Няма операционна система, под която това да е трудно.
   • Всъщност, напълно ОК е да не ползваш абстракцията, която Rails ти дава, ако имаш причина за това. Моято причина е, (1) че искам да видя какво ще стане и (2) засега стават някои хубави неща (PointBreakdowns изгледа).
   • Не е кофти да се пише нестандартен SQL. Ако има нещо, което да е кофти (според мен), това е стандартния SQL. Супер адекватен е, ако правиш компонент, който трябва да може да се преизползва (CMS engine за Rails) или да се deploy-ва на много места (блог платформа). Обаче когато развиваш собствено, специфично приложение – това изискване отпада. Тогава е хубаво да се възползваш от спецификите на базата си, ако има смисъл от това (например PointBreakdowns).

   Публикувано преди над 11 години

Трябва да сте влезли в системата, за да може да отговаряте на теми.