Переход на postgresql (с mysql) в миграциях laravel?

Question

[Alixx]

Имеется windows 10, postgresql 11 (+pgAdmin 4), php 7.2.11, laravel 5.4, локально на компе. Нахожусь в процессе перехода с mysql на postgresql, а именно - переписываю миграции. Оказывается, лара мало заточена под posqtgresql, собственно поэтому поводу и прошу помощи правильно разобраться.

1. autoincrement
$tsble->autoincrement('id'); создаёт поле типа integer с DEFAULT nextval('users_id_seq'::regclass);
Но в postgresql есть есть тип serial, вроде как специально для автоинкрементых айди и создан. Тогда использовать нужно его? Но в миграциях laravel нет такого типа. Тогда оставлять в миграции автоинкремент как есть, а потом после проведения миграции вручную изменить тип поля на serial?

2. unsigned
Оказывается его нет в postgresql. Заменить на CHECK (имя_поля >= 0)? Или ещё какие варианты (если есть, то чем они лучше)? И опять-таки в миграциях лары нет никакого check() - вручную потом в самом postgresql исправлять?

3. массивы
Для mysql использовала string и туда записывала данные в виде json. Для postgresql пока выбрала прямо json. В миграциях он доступен. Или стоит выбрать тип массива? В чём разница между массивами и json в postgresql?

Что-то laravel, как я пока вижу, мало адаптирован к работе с postgresql. Вопросы могут показаться для кого-то глупыми, но тем не менее они вот у меня возникли, почитала - осталась в непонятках. В ларе вообще нет ничего про отличия от Postgresql, поэтому прошу помочь

Answer 1

[JhaoDa]

1. autoincrement
2. unsigned

Базовый уровень — добавить поле нужного типа или поменять тип поля руками через \DB::statement().
Следующий уровень — расширить schema builder и PostgresGrammar.
Уровень надмозга — расширить и сделать пулл-реквест в репу Illuminate.

Более того, в PG 10 появился более правильный способ автоинкремента и Laravel 5.7 его уже поддерживает.

3. массивы

Не поверите, они отличаются тем, что одно — массив, а другое — json. И хоть они и похожи иногда, но это разные типы данных. Документация есть на русском, изучайте.

В ларе вообще нет ничего про отличия от Postgresql

В этом и смысл. Выбор базы данных не относится к ларавел, в идеале вам должно быть не важно, что там за БД. Поэтому искаропки ларавел поддерживает более-менее общий набор типов данных, подменяя их другими, как в случае json и старых версий mysql.
Всё, чего нет и то нужно конкретно вам, вы и должны реализовать. И сделать PR, надеясь, что Тэйлор его не отклонит :) Ну или если наберётся критическая масса тех, кому это надо.

Comments

[Alixx]

Спасибо за развёрнутый ответ!
Я всё почему-то думала, что в ларе должна поддерживать почти все возможные опции для работы с бд. Ну а вы своим постом поставили это восприятие на место) Буду пробовать самостоятельно дописывать нужное в лару, редко такое приходится делать)

[Alixx]

Возник вопрос насчёт generated as identity. Выполняется

DB::statement('ALTER TABLE main.tests ADD COLUMN id integer GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY NOT NULL');

пишет, что миграция проводится успешно. Захожу в pgAdmin 4 в SQL таблицы написано

id integer NOT NULL,
    CONSTRAINT tests_pkey PRIMARY KEY (id)

И в индексах, ограничениях, правилах, зависимостях, свойствах - нигде ничего нет об обозначении этого столбца как столбца идентификации. Или я не там смотрю? Или не работает generated as identity через DB::statement ? Подскажите, что не так может быть?

[JhaoDa]

Alixx, а что, PRIMARY KEY (id) это не идентификация? GENERATED BY DEFAULT AS IDENTITY не относится к типу данных, это определение последовательности (sequence), там и ищите.

[Alixx]

Да, точно, нашла в последовательностях, только в общей вкладке, а не у столбцов, странно, при простом

ADD COLUMN id integer NOT NULL DEFAULT nextval('main.amenes_id_seq'::regclass) PRIMARY KEY;

в зависимых показана и последовательность и функция nextval. Вы писали, что

более правильный способ автоинкремента

а чем он правильней?

[JhaoDa]

Alixx, пройдите по ссылке и прочитайте.

[Alixx]

Я имела ввиду на уровне работы с pgadmin

Answer 2

[Melkij]

Но в postgresql есть есть тип serial

неа, нет его.
Это именно синтаксический сахар вокруг create sequence + integer с DEFAULT nextval('users_id_seq'::regclass)
Посмотрите в pg_dump, не найдёте ни одного serial

вручную изменить тип поля на serial?

alter table foo alter COLUMN i type serial;
ERROR: type "serial" does not exist

А вот не сможете, нет такого типа данных.

2. unsigned
Оказывается его нет в postgresql. Заменить на CHECK (имя_поля >= 0)? Или ещё какие варианты (если есть, то чем они лучше)?

Да, unsigned типов нет. Можно check к полю добавлять, можно сделать create domain сразу с check и использовать имя этого домена в качестве типа данных.

И опять-таки в миграциях лары нет никакого check()

Я думаю в этих миграциях нет почти всего, даже из SQL92 стандарта. Утилиты миграций за исключением тех, что дают выполнять произвольный SQL, обычно ничего не умеют из возможностей базы, стоит лишь чуть копнуть вглубь.

3. массивы
Для mysql использовала string и туда записывала данные в виде json. Для postgresql пока выбрала прямо json. В миграциях он доступен. Или стоит выбрать тип массива? В чём разница между массивами и json в postgresql?

Есть json. В json бывают массивы, бывают объекты, скаляры.
Есть отдельно массивы в postgresql как отдельные типы данных. Вы можете сделать массив из json документов.
Разница между json и массивами - разные наборы функций, операторов.

Что-то laravel, как я пока вижу, мало адаптирован к работе с postgresql.

Раз для mysql вместо json используется string (text видимо всё-таки) - то и для mysql не очень адаптирован. Ну или у вас mysql какой-то очень сильно древний.
Такие конструкторы обычно адаптированы под людей, которые не знают и знать не хотят свою базу.

Comments

[Alixx]

Спасибо за развёрнутый ответ!! Всё поняла, пошла делать)

Answer 3

[Вячеслав Успенский]

Не переживайте, как верно подметил

Melkij

Такие конструкторы обычно адаптированы под людей, которые не знают и знать не хотят свою базу.

Как правило, любые нестандартные вещи из коробки поддерживаются чуть менее чем никак. Я бы даже сказал все, что выходит за грани примитивного. Более того в некоторых языках сами драйверы накладывают ограничения. Например PHP не умеет работать с PostgreSQL массивами, совсем. Как правило обходят это дело так ну или сразу используют jsonb

Comments

[Alex Wells]

Дело не всегда в том, кто что хочет знать или использовать, а в том, сколько есть времени на реализацию того или инного решения, а так же желаемый уровень абстракции от implementation-specific вещей.

Большинство вещей, благо, +- одинаковы и решаются средствами из коробки. Да, не идеально, но и не плохо, точно не занимает кучу времени и абстрагирует достаточно, что бы процесс перехода с одной на другую хотя бы был возможен.

Самое главное - что бы была возможность расширить имеющийся из коробки функционал как угодно - но это не про eloquent, к сожалению.