Re: Support for CTAS statement with ORM API?

[Markus Elfring]

> To both of these - the Django ORM doesn't work in the same way as SQLAlchemy.

I guess that it can become interesting to clarify software differences a bit 
more.


> Django does not have such a representation,

Thanks for such background information.


> it bundles everything in the Query class.

Will this aspect trigger any further concerns for software evolution?


> I've tidied my code snippet a bit and posted it on my blog
> at https://adamj.eu/tech/2019/04/29/create-table-as-select-in-django/ .

I am curious if the development attention will grow also for this area.

Regards,
Markus

-- 
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/ca05644f-e736-33ab-ea81-6043f4a86a01%40web.de.
For more options, visit https://groups.google.com/d/optout.

Re: Support for CTAS statement with ORM API?

[Adam Johnson]

Hi Markus

It seems that the functionality is already usable by this class library
> in a convenient way.


How do you think about the addition of a base class like “table”

with the method “create(parameters)” (if it would not be provided so far)?


To both of these - the Django ORM doesn't work in the same way as
SQLAlchemy. SQLAlchemy has a representation of the query underneath that's
close to SQL. This is how an extra CreateTableAs class can be added that
neatly fits.

Django does not have such a representation, it bundles everything in the
Query class. I think my code snippet is the closest we can get to a way of
integrating. However, it is less code since rather than creating a class,
as it performs direct string manipulation on the SQL.

Would any contributors like to adjust the software situation a bit more
> here?


I am not sure such a function belongs in Django, at least at this time,
since your request is the first I can find in its history. We're always a
bit conservative about adding new features since they will need maintaining
forever.

I've tidied my code snippet a bit and posted it on my blog at
https://adamj.eu/tech/2019/04/29/create-table-as-select-in-django/ . If it
gets some more coverage maybe that's an indicator it's worth adding into
Django core.

Thanks,

Adm

On Sun, 28 Apr 2019 at 12:43, Markus Elfring  wrote:

> > AFAIU from the link, the source code is extending SQLAlchemy to support
> CTAS,
> > so it's not built-in there.
>
> It seems that the functionality is already usable by this class library
> in a convenient way.
>
>
> > It's similarly possible to do a CTAS in Django with a little raw SQL
> > and the ORM's internal API (which is undocumented).
>
> Would any contributors like to adjust the software situation a bit more
> here?
>
>
> > I guess this could be wrapped up in a function,
>
> This is likely.
>
>
> > like "create_table_as(table_name, queryset)" ? Thoughts?
>
> How do you think about the addition of a base class like “table”
> with the method “create(parameters)” (if it would not be provided so far)?
>
> 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/CAMyDDM1Q0PJQdVhrpWM1h42o-gQD2AfTBCmTE9pwPfz%2BFg3fQg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Database Router Abstract Base Class (ABC)

[Adam Johnson]

I'm a bit ambivalent on adding such a class. Many features even in core
Python don't provide base classes and instead rely on duck-typing +
documentation. The amount of time saved globally will probably be less than
the time we've spent discussing it so far.

I think a more valuable piece of code would be the system check, since that
would validate it's all spelled correctly, for all developers, whether or
not their editor has auto-complete. It would also work going forwards
if/when the signatures change.

On Sun, 28 Apr 2019 at 10:35, Rick van Hattem  wrote:

> On Sun, 28 Apr 2019 at 11:30, Adam Johnson  wrote:
>
>> I don't think this would be that helpful, Django relies on ducktyping,
>> and the router docs (
>> https://docs.djangoproject.com/en/2.2/topics/db/multi-db/ ) clearly
>> document the signatures, and that the methods are all optional:
>>
>> A router doesn’t have to provide *all* these methods – it may omit one
>>> or more of them. If one of the methods is omitted, Django will skip that
>>> router when performing the relevant check.
>>
>>
> So in that case not a abstract base class but just a regular base class
> (which is why I placed the abstract part between ()). The advantage of
> having a base class is also that your editor can automatically complete the
> signature if you're planning to implement it.
>
> Would there be anything against it though? A non-abstract base class in
> that case :)
>
> ~rick
>
> --
> 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/CAJAwA%3DzhuM4OL0JzshGHQK2nLw9YL2aLtEjGqrQAOwyvYE6Wiw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
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/CAMyDDM0qzrRqDTkVA71emNs9773f5PjY___R-Xuk-Ucwg3JAcA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[J. Pic]

If you don't want to break git blame then I suppose you could create a
branch to replay each commit with black.

-- 
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/CAC6Op18mCH1Gxjt2%2BKmsBjrq1gxE%2BgUUs8NNu_Y9dRG%3Dbij%3DjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Paveł Tyślacki]

Just short hint about git blame.

Github has functionality to get more deep git blame:
https://help.github.com/en/articles/tracking-changes-in-a-file, more over
pycharm has similar functionality too (potentially another editors and IDE
have too). I suggest that git blame is more tooling issue, not changes
approach, because for another refactoring and active development you can
have the same issue with git blame.

Regards
Paveł

On Mon, 29 Apr 2019 at 10:12, Carlton Gibson 
wrote:

> Hi Alex.
>
> So I use git blame on Django *a lot: *a new ticket comes in, I have no
> idea at all how to triage it so I need to look at the history to make a
> sensible decision. I use git blame to find the commit, to find the original
> ticket, in which there's a discussion, which 🤞 explains why things are as
> they are. (Mostly...)
>
> But we're already at the the point where more times than not I need to
> skip multiple commits to get back to the original decision.
>
> Look at `master` right now.
> https://github.com/django/django/commits/master
> (Screenshot attached)
>
> The last three commits from this morning are all "tidy-ups" that obscure
> the history. This is typical. Rarely now is there such a old block that
> hasn't been adjusted at all. So it's normal to have to jump commits.
>
> A big Black commit will add to this. (It's the concern I do have.) But
> it's not a game changer. It's just more of the same. I'm pretty sure it's
> the motivation needed to up my git blame foo to the next level, at which
> point I'll likely save time ironically.
>
> For this reason, weighed against the benefits, I don't think the git
> history should be a blocker. I hope that makes sense.
>
> Kind Regards,
>
> Carlton
>
>
>
> --
> 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/01b0bcb5-3540-455e-b06e-d16ad2ec04d8%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAL6gfQZ6eAtHntmPh%3DxR-Raf7ro4wM%3DbCpny7nH_AMmHdj91ow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Reports - April 2019

[Mariusz Felisiak]

Week ending April 28, 2019.

*Triaged:*
https://code.djangoproject.com/ticket/30387 - Move more Windows-specific 
docs to use Python official launcher. (accepted)
https://code.djangoproject.com/ticket/30388 - inspectdb generates unique 
ForeignKey instead of OneToOneField. (accepted)
https://code.djangoproject.com/ticket/30391 - .get() ignores .using(). 
(worksforme)
https://code.djangoproject.com/ticket/30386 - Admin foreign key widgets 
don't quote keys. (accepted)
https://code.djangoproject.com/ticket/30369 - Creating database tables from 
queries based on ORM API (wontfix)
https://code.djangoproject.com/ticket/30393 - Add validation of target 
argument in startapp command. (accepted)
https://code.djangoproject.com/ticket/30396 - Add a system check for 
uniqueness of partial indexes and constraints names. (created)
https://code.djangoproject.com/ticket/30397 - Allow app_label and class to 
be specified in the name argument for indexes and constraints. (created)
https://code.djangoproject.com/ticket/30400 - Improve typography of user 
facing strings. (accepted)
https://code.djangoproject.com/ticket/30401 - Clarification about when a 
default value is assigned to a ModelField (wontfix)
https://code.djangoproject.com/ticket/30383 - Performance issue with 
ThreadPoolExecutor/Multiprocessing. (worksforme)
https://code.djangoproject.com/ticket/30404 - "Using a model formset in a 
view" example doesn't handle invalid formset. (worksforme)
https://code.djangoproject.com/ticket/30403 - Test namespace packages 
discover fails to load module. (invalid)
https://code.djangoproject.com/ticket/30402 - Django default_site admin 
configuration doesn't register anything (worksforme)
https://code.djangoproject.com/ticket/30406 - Charfield max length error. 
(invalid)
https://code.djangoproject.com/ticket/30407 - Modelform initial values 
override instance values when both are set. (wontfix)
https://code.djangoproject.com/ticket/30408 - CheckConstraint with lookup 
using LIKE & % crash on PostgreSQL. (accepted)

*Reviewed/committed:*
https://github.com/django/django/pull/11254 - Fixed #30385 -- Restored 
SearchVector(config) immutability.
https://github.com/django/django/pull/11258 - Fixed #30387 -- Enhanced docs 
CLI examples in Unit tests and Install Django on Windows.
https://github.com/django/django/pull/11217 - Fixed #30365 -- Fixed syntax 
highlighting in SQL examples.
https://github.com/django/django/pull/11079 - Fixed #29810 -- Fixed crash 
of select_related() on FilteredRelation with empty result.
https://github.com/django/django/pull/11267 - Changed tuple 
Mate.unique_together/permissions to lists in docs.
https://github.com/django/django/pull/11244 - Fixed #30342 -- Removed a 
system check for LANGUAGES_BIDI setting.
https://github.com/django/django/pull/11273 - Refs #30241 -- Fixed 
BytesWarning emitted in test_translation tests.
https://github.com/django/django/pull/11260 - Fixed #30388 -- Made 
inspectdb generate OneToOneFields rather than 
ForeignKey(unique/primary_key=True).
https://github.com/django/django/pull/11270 - Fixed #30393 -- Added 
validation of startapp's directory option.
https://github.com/django/django/pull/11169 - Fixed #30318 -- Added check 
for importability of arguments of custom error handler views.
https://github.com/django/django/pull/11166 - Fixed #30312 -- Relaxed admin 
check from django.contrib.sessions to SessionMiddleware subclasses.
https://github.com/django/django/pull/11263 - Fixed #30361 -- Increased the 
default timeout of watchman client to 5 seconds and made it customizable.
https://github.com/django/django/pull/11283 - Fixed #30351 -- Handled 
pre-existing permissions in proxy model permissions data migration.

*Reviewed:*
https://github.com/django/django/pull/11276 - Fixed #30399 -- Changed 
django.utils.html.escape()/urlize() to use html.escape()/unescape().

*Authored:*
https://github.com/django/django/pull/11275 - Fixed #30362 -- Noted partial 
indexes and constraints restrictions with abstract base classes.

Best regards,
Mariusz

-- 
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/3341a5dd-c24f-4097-a350-f302f6047d30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Carlton Gibson]

Hi Alex. 

So I use git blame on Django *a lot: *a new ticket comes in, I have no idea 
at all how to triage it so I need to look at the history to make a sensible 
decision. I use git blame to find the commit, to find the original ticket, 
in which there's a discussion, which 🤞 explains why things are as they 
are. (Mostly...)

But we're already at the the point where more times than not I need to skip 
multiple commits to get back to the original decision. 

Look at `master` right now. https://github.com/django/django/commits/master
(Screenshot attached) 

The last three commits from this morning are all "tidy-ups" that obscure 
the history. This is typical. Rarely now is there such a old block that 
hasn't been adjusted at all. So it's normal to have to jump commits. 

A big Black commit will add to this. (It's the concern I do have.) But it's 
not a game changer. It's just more of the same. I'm pretty sure it's the 
motivation needed to up my git blame foo to the next level, at which point 
I'll likely save time ironically. 

For this reason, weighed against the benefits, I don't think the git 
history should be a blocker. I hope that makes sense. 

Kind Regards,

Carlton



-- 
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/01b0bcb5-3540-455e-b06e-d16ad2ec04d8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.