Re: Recomended front ends?
От | Adrian Klaver |
---|---|
Тема | Re: Recomended front ends? |
Дата | |
Msg-id | a4baded5-fe45-bb7b-6c0a-264fef7af5d8@aklaver.com обсуждение исходный текст |
Ответ на | Re: Recomended front ends? (Daniele Varrazzo <daniele.varrazzo@gmail.com>) |
Ответы |
Re: Recomended front ends?
|
Список | pgsql-general |
On 8/27/19 8:04 AM, Daniele Varrazzo wrote: > 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". Django takes Postgres as it's reference database which makes things easier, especially when you add in contrib.postgres(https://docs.djangoproject.com/en/2.2/ref/contrib/postgres/) > > 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. +1 > > 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 > > > -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: