Re: Recomended front ends?

Поиск
Список
Период
Сортировка
От Daniele Varrazzo
Тема Re: Recomended front ends?
Дата
Msg-id CA+mi_8ZZPY4v8ic_XEOdQiT7V48A8hOvaW1cPEB5b6+icTTnrQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Recomended front ends?  ("Peter J. Holzer" <hjp-pgsql@hjp.at>)
Ответы Re: Recomended front ends?  (Adrian Klaver <adrian.klaver@aklaver.com>)
Re: Recomended front ends?  ("Peter J. Holzer" <hjp-pgsql@hjp.at>)
Список pgsql-general
On Sun, Aug 11, 2019 at 7:49 PM Peter J. Holzer <hjp-pgsql@hjp.at> wrote:

> Django lets you use "unmanaged" tables, but it is quite noticeable that
> this isn't the primary use case.

It isn't, but it's the best way to use Django for database-literate
people. It's enough to ignore the Django sale pitch of the database as
a replaceable element and just assume Postgres. In Docker times you
don't need SQLite to create a poorly representative "development
database".

You can just ignore the Django ORM for the whole data-definition layer
and migrations: you can have your database schema, with comments, in
your source code, with strict control of what's in the db (exotic
index definitions, exclusion constraints, writable views...) and only
use the ORM to read and manipulate data, as long as the Django model
"resembles" the database table.
Schema migrations are easy to deal with using SQL patches [1], and
complete, unlike any Model-based migration system.

Using the Django ORM to create complex queries is a joy (especially
nesting subqueries), and you don't lose all the other Django
facilities (decent auth model, decent CRUD interface, customisation
when "decent" is not enough).

[1] https://gist.github.com/dvarrazzo/4161070

-- Daniele



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

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: Include a connection pooler in Postgres
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: [ext] Re: Pointers towards identifying bulk import bottleneck(walwriter tuning?)