django-query-profil VS azure-docs

But that's still not backend-specific SQL?

There should be an interface method for this. Why does psycopg call it mogrify?

https://django-debug-toolbar.readthedocs.io/en/latest/panels... :

> debug_toolbar.panels.sql.SQLPanel: SQL queries including time to execute and links to EXPLAIN each query

But debug toolbars mostly don't work with APIs.

https://github.com/django-query-profiler/django-query-profil... :

> Django query profiler - one profiler to rule them all. Shows queries, detects N+1 and gives recommendations on how to resolve them

https://github.com/jazzband/django-silk :

> Silk is a live profiling and inspection tool for the Django framework. Silk intercepts and stores HTTP requests and database queries before presenting them in a user interface for further inspection

I agree that this stuff can definitely be handled better.

https://github.com/django-query-profiler/django-query-profil... has a neat option for detecting likely N+1 queries. I usually use the Django Debug Toolbar for this.

Django's ".only()" method lets you specify just the columns you want to retrieve - with the downside that any additional property access can trigger another SQL query. I thought I'd seen code somewhere that can turn those into errors but I'm failing to dig it up again now.

I've used the assertNumQueries() assertion in tests to guard against future changes that accidentally increase the number of queries being made without me intending that.

The points you raise are valid, but there are various levels of mitigations for them. Always room for improvement though!

Explained here: https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/backup/backup-azure-alternate-dpm-server.md

Official doc on runbook limitations: https://github.com/MicrosoftDocs/azure-docs/blob/main/includes/azure-automation-service-limits.md

I dont think that works:

    > git clone --depth 1 https://github.com/MicrosoftDocs/azure-docs

Does anyone have any idea why this is? I found a github issue that basically describes the issue as well but there is no satisfying solution. Can you really not use native azure monitoring solutions if you migrate your VMs to azure? That seems hard to believe and I hope I'm just missing something. I'm very thankful for any advice at this point.

It appears that there is a 512kb payload limit with runbook webhooks, which I can only find mention of on this git file:https://github.com/MicrosoftDocs/azure-docs/blob/main/includes/azure-automation-service-limits.mdThe data I was including in the web activity body appears to be just under this limit and would trigger the runbook without issue. But with the extra data webhook activities include in the body it puts it over the limit and never triggers it. Unfortunately Data Factory doesn't handle this situation properly and the activity runs indefinitely until you cancel it (despite the timeout configured).The work around for me was to add a foreach activity and put the webhook activity inside of that.