>
> This is an usual challenge for such software extensions, isn't it?
It's more around having an API that makes intuitive sense to ORM users.
Django is very model-focused and the ORM is mostly designed to work with
tables that are created by migrations.
I published examples where data processing approaches are shown
(also together with applications of the class library “SQLAlchemy”).
AFAIU from the link, the source code is extending SQLAlchemy to support
CTAS, so it's not built-in there.
It's similarly possible to do a CTAS in Django with a little raw SQL and
the ORM's internal API (which is undocumented). You can to compile the
query for a QuerySet and prefix it with CTAS syntax before running it. For
example:
In [1]: from gargoyle.models import Switch
In [2]: Switch.objects.filter(pk__gt=1)
Out[2]: <QuerySet []>
In [7]: from django.db import DEFAULT_DB_ALIAS, connection
In [8]:
connection.ops.compiler('SQLCompiler')(Switch.objects.filter(pk__gt=1).query,
connection, DEFAULT_DB_ALIAS).as_sql()
Out[8]:
('SELECT "gargoyle_switch"."key", "gargoyle_switch"."value",
"gargoyle_switch"."label", "gargoyle_switch"."date_created",
"gargoyle_switch"."date_modified", "gargoyle_switch"."description",
"gargoyle_switch"."status" FROM "gargoyle_switch" WHERE
"gargoyle_switch"."key" > %s',
('1',))
In [9]: sql, params =
connection.ops.compiler('SQLCompiler')(Switch.objects.filter(pk__gt=1).query,
connection, DEFAULT_DB_ALIAS).as_sql()
In [10]: sql = 'CREATE TABLE foobar AS ' + sql
In [11]: connection.cursor().execute(sql, params)
Out[11]: <django.db.backends.sqlite3.base.SQLiteCursorWrapper at
0x1115a2f78>
In [12]: cursor = connection.cursor()
In [13]: cursor.execute('SELECT * FROM foobar')
Out[13]: <django.db.backends.sqlite3.base.SQLiteCursorWrapper at
0x1115a2e58>
In [14]: list(cursor.fetchall())
Out[14]: []
I guess this could be wrapped up in a function, like
"create_table_as(table_name, queryset)" ? Thoughts?
On Fri, 26 Apr 2019 at 12:03, Markus Elfring <markus.elfr...@web.de> wrote:
> > CTAS can be useful in some cases,
>
> Thanks for such feedback.
>
>
> > but I can't imagine how we'd fit it into the Django ORM nicely.
>
> This is an usual challenge for such software extensions, isn't it?
>
>
> > There wouldn't be a model for the correspondingly created table.
>
> Can a data model be determined from its creation parameters?
>
>
> > Have you got a suggestion for the way you'd like to see it working?
>
> I published examples where data processing approaches are shown
> (also together with applications of the class library “SQLAlchemy”).
> I would like to be able to choose between the use of materialized views
> (or snapshots) and a concrete database table.
> How often will different development and software run time characteristics
> matter for these interfaces?
>
> Regards,
> Markus
>
--
Adam
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAMyDDM1BB63GwrxhE90WryYXzhk-mD0oGPO2x3ph9dXYRWaqQw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
