Re: [PATCH] pgarchives: Bugfix: allow message's parentid to be null

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: [PATCH] pgarchives: Bugfix: allow message's parentid to be null
Дата
Msg-id CABUevEz5VqyjTN9p684n0Zr++V_DbRHtoNE1TY0h6Nsewi-YPQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] pgarchives: Bugfix: allow message's parentid to be null  (Célestin Matte <celestin.matte@cmatte.me>)
Список pgsql-www
Дерево обсуждения
On Wed, Oct 27, 2021 at 12:04 PM Célestin Matte <celestin.matte@cmatte.me> wrote:
>
> That said, I think the correct solutoin is still, as I mentioned in one of the other threads, to completely move everything into the initial migration, instead of doing a piecemeal hack that's going to result in a lot of small migrations for no real reason. We should  just accept that the existing one is broken and replace it.

Can everything be moved to django's model though? The schema.sql file defines several other components (indexes, text search configurations, text search dictionaries, functions, triggers) and I'm not sure django is able to handle all of that by itself. Is it? Or do you only want to move tables?

The models can't handle them, but migrations can.

I'm thinking similar to pglister, where we use django models to create the parts that *can* be created, and then RunSQL() migrations to do the rest. That way the pure SQL parts can still run as part of the same flow, and can be mixed in with the django generated ones. The end result in the database should be the same, but avoiding to have to maintain a separate .sql file for it to keep in sync. 

I suggest moving everything, for that reason -- to ensure the order of application.

--

В списке pgsql-www по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: [PATCH] pgweb: Search: bugfix: replace sites.baseurl with sites.hostname
Следующее
От: Célestin Matte
Дата:
Сообщение: [PATCH] pglister: Add possibility to override settings.py in settings_local.py