ORM — це просто

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Привіт друзі! Нещодавно жалівся в блозі, що не маю з ким поговорити про код, який я пишу, тож поділюсь із вами, бо нарешті маю трохи вільного часу 😃

В програмуванні є різні підходи до роботи з базами даних:

• можна написати код, який просто виконує SQL запити. Це просто і зрозуміло
• А можна використати ORM (Object-relational mapping) — технологію, що зв’язує кожен запис в таблиці БД з відповідним об’єктом. Як от код

class Person(Base):
    id = Column(Integer, primary_key=True)
    name = Column(String, nullable=False)
    age = Column(Integer, nullable=True)

буде відповідати запису в SQL таблиці з трьома колонками з відповідними іменами

Це зручно для розробника:
🟢створив об’єкт — додався запис в базу
🟢змінив — і зміни вже там
🟢видалив — ви зрозуміли
🟢а працювати з даними з пов’язаних таблиць — взагалі дуже просто і приємно!

# уявімо, що у нас є таблиця Cars і кожна людина може мати декілька машин
# з даними можна працювати як зі списком
for car in person.cars:
    print(car.name)

Але на практиці і я, і багато моїх колег і знайомих все ще частіше користуємось старим добрим SQL в коді. Тому що

• «та там щось складно, це ж розбиратись треба»
• «ну ми вже багато написали, переписувати довго буде»
• «а якщо щось зміниться, як мігрувати?»

І от, нещодавно в мене з’явилась задача написати тести, що використовують дані з 10+ нових таблиць, при чому в коді вже був написаний абстрактний шар коду з SQL на інші 10 таблиць. Раніше я б тільки мріяв про ORM, бо руками створювати моделі для купи таблиць з купою полів — неприємна багатогодинна рутина. Але я вирішив спробувати мігрувати все на ORM, щоб дізнатись, наскільки це складно і довго насправді, використовуючи ШІ.

Пишу на Python і обрав для роботи одну з найпопулярніших ORM — SQLAlchemy.

✅ По-перше, я створив моделі — скопіював структуру таблиць у вигляді SQL запитів (будь-який редактор таке вміє) і попросив Copilot згенерувати мені моделі. На все витратив десь годину

create table persons
(
    id   INTEGER not null
        primary key,
    name VARCHAR not null,
    age  INTEGER
);

✅ По-друге, переписав існуючі функції, що читали чи модифікували дані, замінюючи SQL відповідними моделями. Витратив ще годину. Тобто, був, умовно, метод get_persons_by_age(age: int) -> list[tuple], де «під капотом» був написаний SQL запит. Він і залишився, але всередині працює через ORM. Тільки повертав список списків* значень, а тепер — список об’єктів. Що навіть спрощує роботу з ним.

✅ По-третє, написав нові функції вже на нові таблиці. Їх було багато, тож 2 години. При чому, писав навіть не зовсім сам. Пишучи назву функції, Copilot сам пропонував мені підходящий код, тож робота йшла дуже швидко!

✅ Запустив тести, щоб перевірити, чи нічого не зламав, пофіксив кілька перетворень типів і все! На повну міграцію я витратив менше 1 дня!

Як наслідок я, і інші інженери використовують ці моделі для швидкого написання інтеграційних тестів для перевірки прототипів. Код став красивіший і зрозуміліший.

Тож якщо ви сумніваєтесь — рекомендую спробувати. З ШІ це питання годин, а не днів😉