[PATCHES] pgarchives: merge schema.sql into Django's model

As discussed in previous threads before [1, 2], database creations file are currently split between the Django model and a SQL file. Discrepancy in the database's definition exists between them. As a consequence, the database cannot be created easily.
This series of patches merge schema.sql into Django's model, and adds specific postgres components that cannot be handled by Django's ORM using RunSQL() in a migration file.

Please also note that I integrated several other patches to avoid multiple migration files:
- I allowed message.parentid to be null, as discussed in [1]. This can cause Internal Server Errors in views.py, which are fixed by the second patch.
- I used BinaryFields for bytea columns (message.rawtxt and attachments.attachment), which seems to be the way to integrate bytea into Django

It may be a good opportunity to remove all mentions of pg_dict, pg_stop and associated file. I'm not sure of the consequences of this. According to [2], these are the remains of an aborted idea.
Also, what does tsparer bring? Can the installation of pgarchives be simplified by replacing it with pg_catalog.english?

[1]: /message-id/CABUevEyFpYPEHh0AAyTAsgymRKOOVA1SY_pDHPCbBQQ9BawfTA%40mail.gmail.com
[2]: /message-id/CABUevEy_i1xAKscMv4KZ0%3DbE8050bBcQfWaNyjwZZBofZx7JgQ%40mail.gmail.com
--
Célestin Matte

Hi there,

Gentle reminder that this patch has not been reviewed and may have been forgotten

On 03/02/2022 14:30, Célestin Matte wrote:
> As discussed in previous threads before [1, 2], database creations file are currently split between the Django model and a SQL file. Discrepancy in the database's definition exists between them. As a consequence, the database cannot be created easily.
> This series of patches merge schema.sql into Django's model, and adds specific postgres components that cannot be handled by Django's ORM using RunSQL() in a migration file.
>
> Please also note that I integrated several other patches to avoid multiple migration files:
> - I allowed message.parentid to be null, as discussed in [1]. This can cause Internal Server Errors in views.py, which are fixed by the second patch.
> - I used BinaryFields for bytea columns (message.rawtxt and attachments.attachment), which seems to be the way to integrate bytea into Django
>
> It may be a good opportunity to remove all mentions of pg_dict, pg_stop and associated file. I'm not sure of the consequences of this. According to [2], these are the remains of an aborted idea.
> Also, what does tsparer bring? Can the installation of pgarchives be simplified by replacing it with pg_catalog.english?
>
>
> [1]: /message-id/CABUevEyFpYPEHh0AAyTAsgymRKOOVA1SY_pDHPCbBQQ9BawfTA%40mail.gmail.com
> [2]: /message-id/CABUevEy_i1xAKscMv4KZ0%3DbE8050bBcQfWaNyjwZZBofZx7JgQ%40mail.gmail.com

--
Célestin Matte

Hello,

I sent these patches over a year ago. Can they be reviewed?
Patches I sent earlier were rejected because a full merge of the database creation process was a better approach. This series of patches does exactly that.

On 07/05/2022 11:32, Célestin Matte wrote:
> Hi there,
>
> Gentle reminder that this patch has not been reviewed and may have been forgotten
>
> On 03/02/2022 14:30, Célestin Matte wrote:
>> As discussed in previous threads before [1, 2], database creations file are currently split between the Django model and a SQL file. Discrepancy in the database's definition exists between them. As a consequence, the database cannot be created easily.
>> This series of patches merge schema.sql into Django's model, and adds specific postgres components that cannot be handled by Django's ORM using RunSQL() in a migration file.
>>
>> Please also note that I integrated several other patches to avoid multiple migration files:
>> - I allowed message.parentid to be null, as discussed in [1]. This can cause Internal Server Errors in views.py, which are fixed by the second patch.
>> - I used BinaryFields for bytea columns (message.rawtxt and attachments.attachment), which seems to be the way to integrate bytea into Django
>>
>> It may be a good opportunity to remove all mentions of pg_dict, pg_stop and associated file. I'm not sure of the consequences of this. According to [2], these are the remains of an aborted idea.
>> Also, what does tsparer bring? Can the installation of pgarchives be simplified by replacing it with pg_catalog.english?
>>
>>
>> [1]: /message-id/CABUevEyFpYPEHh0AAyTAsgymRKOOVA1SY_pDHPCbBQQ9BawfTA%40mail.gmail.com
>> [2]: /message-id/CABUevEy_i1xAKscMv4KZ0%3DbE8050bBcQfWaNyjwZZBofZx7JgQ%40mail.gmail.com
>
>

--
Célestin Matte

Adding a patch to this series to fix an issue with this migration: default value set in django is not taken account in load_messages.py because django's ORM is not used there, which leads to crashes.

On 03/02/2022 14:30, Célestin Matte wrote:
> As discussed in previous threads before [1, 2], database creations file are currently split between the Django model and a SQL file. Discrepancy in the database's definition exists between them. As a consequence, the database cannot be created easily.
> This series of patches merge schema.sql into Django's model, and adds specific postgres components that cannot be handled by Django's ORM using RunSQL() in a migration file.
>
> Please also note that I integrated several other patches to avoid multiple migration files:
> - I allowed message.parentid to be null, as discussed in [1]. This can cause Internal Server Errors in views.py, which are fixed by the second patch.
> - I used BinaryFields for bytea columns (message.rawtxt and attachments.attachment), which seems to be the way to integrate bytea into Django
>
> It may be a good opportunity to remove all mentions of pg_dict, pg_stop and associated file. I'm not sure of the consequences of this. According to [2], these are the remains of an aborted idea.
> Also, what does tsparer bring? Can the installation of pgarchives be simplified by replacing it with pg_catalog.english?
>
>
> [1]: /message-id/CABUevEyFpYPEHh0AAyTAsgymRKOOVA1SY_pDHPCbBQQ9BawfTA%40mail.gmail.com
> [2]: /message-id/CABUevEy_i1xAKscMv4KZ0%3DbE8050bBcQfWaNyjwZZBofZx7JgQ%40mail.gmail.com

--
Célestin Matte

Adding the patch mentioned in another thread [1], as a bugfix to the patch creating two indexes on list_threads(listid)

[1] /message-id/4999fcd4-7b9e-3d25-42fa-1b322c3867a0%40cmatte.me
--
Célestin Matte

New series of this patch rebased on current master branch.
Fixes primary_key issues mentioned in a previous thread [1].

[1]: /message-id/CABUevExzjRo-=9Hg4CDdnGHuQB1L6uAwekni0mz-1CECaMcGZA@mail.gmail.com

On 03/02/2022 14:30, Célestin Matte wrote:
> As discussed in previous threads before [1, 2], database creations file are currently split between the Django model and a SQL file. Discrepancy in the database's definition exists between them. As a consequence, the database cannot be created easily.
> This series of patches merge schema.sql into Django's model, and adds specific postgres components that cannot be handled by Django's ORM using RunSQL() in a migration file.
>
> Please also note that I integrated several other patches to avoid multiple migration files:
> - I allowed message.parentid to be null, as discussed in [1]. This can cause Internal Server Errors in views.py, which are fixed by the second patch.
> - I used BinaryFields for bytea columns (message.rawtxt and attachments.attachment), which seems to be the way to integrate bytea into Django
>
> It may be a good opportunity to remove all mentions of pg_dict, pg_stop and associated file. I'm not sure of the consequences of this. According to [2], these are the remains of an aborted idea.
> Also, what does tsparer bring? Can the installation of pgarchives be simplified by replacing it with pg_catalog.english?
>
>
> [1]: /message-id/CABUevEyFpYPEHh0AAyTAsgymRKOOVA1SY_pDHPCbBQQ9BawfTA%40mail.gmail.com
> [2]: /message-id/CABUevEy_i1xAKscMv4KZ0%3DbE8050bBcQfWaNyjwZZBofZx7JgQ%40mail.gmail.com

--
Célestin Matte