Oracle遷移Mysql的sql語句修改需建立的function程式碼
阿新 • • 發佈：2022-12-07
django請求生命週期流程圖
1.Django請求的生命週期的含義
Django請求的生命週期是指：當用戶在瀏覽器上輸入URL到使用者看到網頁的這個時間段內，Django後臺所發生的事情。
2.Django請求的生命週期圖解及流程
1.瀏覽器預設市=是基於HTTP協議傳送請求的 2.傳送請求進入一個web服務閘道器介面，其實就是wsgiref（幫我們分裝了socket程式碼，幫我們把請求過來的數進行資料處理，變成了一個大字典）它是Django預設的，但是它的併發能力特別低非常差，所以在Django上線之後都會切換為uwsgi,該服務併發能力強，併發量大 3.wsgiref與uwsgi都是屬於WSG協議，它們倆個是實現這個協議的模組 4.請求進來的時候拆建資料，響應走的時候封裝資料 ------->進入了Django後端 1.首先會經過一個Django中介軟體，請求會經過它的層層篩選，才會進入urls.py 2.urls.py(路由層)，進來之後完成一個地址的匹配，檢視功能是否開設好了，如果開設好了就會進入views.py(檢視層)，執行核心邏輯，如果需要模板進入模板層 3.templates資料夾(模板層)，models.py(模型層)，模板層可能會需要用到模板語法，然後進入模型層拿取資料，用orm進入資料庫操作資料，返回一個數據，然後orm會操作封裝成物件，回到views.py層，然後會做一個模板渲染，最後依次返回
3.Django的請求生命週期(分佈解析)
瀏覽器 傳送請求(HTTP協議) web服務閘道器介面 1.請求來的時候解析封裝 響應走的時候打包處理 2.django預設的wsgiref模組不能承受高併發 最大隻有1000左右 上線之後會替換成uwsgi來增加併發量 3.WSGI跟wsgiref和uwsgi是什麼關係 WSGI是協議 wsgiref和uwsgi是實現該協議的功能模組 django後端 1.django中介軟體(暫時不考慮 後面講) 類似於django的保安 門戶 2.urls.py 路由層 識別路由匹配對應的檢視函式 3.views.py 檢視層 網站整體的業務邏輯 4.templates資料夾 模版層 網站所有的html檔案 5.models.py 模型層 ORM 額外擴充套件:快取資料庫的作用
路由層
1.路由匹配
path('網址字尾',函式名)
一旦網址字尾匹配上了就會自動執行後面的函式
並結束整個路由的匹配
ps:ip和埠號後面必須要家斜槓的
首先它會去檢視一遍有沒有這個地址，然後發現沒有，301是重定向的狀態碼，那麼此時它會考慮給加一個/去重新執行一次，所有就有了倆次
路由結尾的斜槓
預設情況下不寫斜槓 django會做二次處理 第一次匹配不上 會讓瀏覽器加斜槓再次請求 django配置檔案中可以指定是否自動新增斜槓 APPEND_SLASH = False(預設是True,改成false的時候，不加的話就不能訪問到了)
2.path轉換器
轉換器只有在django2以上才會有
當網址字尾不固定的時候 可以使用轉換器來匹配
'int': IntConverter(),
'path': PathConverter(),
'slug': SlugConverter(),
'str': StringConverter(),
'uuid': UUIDConverter(),
以後不知道固定的檢視函式後面寫什麼就這麼寫：
path('func/<int:year>/<str:info>/', views.func)
轉換器匹配到的內容會當做檢視函式的關鍵字引數傳入
轉換器有幾個叫什麼名字 那麼檢視函式的形參必須對應
def func(request,year,info):
pass
在固定的路由後面新增些不確定的數
3.re_path正則匹配
re_path('test', views.test),
re_path('testadd', views.testadd),
輸入網址：http://127.0.0.1:8000/testadd的時候，返回的是test的內容，re_path的特點是在我們輸入的網址的字尾，它會去匹配，只要能匹配到這個字尾的，就算匹配上了
1.怎麼去區分開呢？？
re_path('test/', views.test),
re_path('testadd/', views.testadd),
加上/後它完整的是test/，所以它只能匹配到它自己的
2.但是還存在問題
http://127.0.0.1:8000/wfdrfffg/test/egddddddd/6ygg
這個樣子還能匹配到，不太精準
那麼如果想要使用正則去做匹配的話，在前面加上^,後面加上$
re_path('^test/$', views.test)
3.re_path(正則表示式,函式名)
一旦網址字尾的正則能夠匹配到內容就會自動執行後面的函式
並結束整個路由的匹配
當網址字尾不固定的時候 可以使用轉換器來匹配
4.正則匹配之無名分組
re_path('^test/(\d+)/', views.test)
正則表示式匹配到的內容會當做檢視函式的位置引數傳遞給檢視函式
5.正則匹配之有名分組
re_path('^test/(?P<year>\d+)/(?P<others>.*?)/', views.test)
正則表示式匹配到的內容會當做檢視函式的關鍵字引數傳遞給檢視函式
6.django版本區別
在django1.11中 只支援正則匹配 並且方法是 url()
django2,3,4中 path() re_path() 等價於 url()
反向解析
1.什麼是反向解析
當路由頻繁變化的時候，html介面與後端上的連線地址如何做到動態解析？
根據自己設定的一個別名，動態解析出一個結果，該結構可以直接訪問對應的url
2.反向解析概念
通過一些方法得到一個結果 該結果可以直接訪問對應的url觸發檢視函式
實現url路由頻繁變化，html介面與後端動態解析連線地址操作步驟:
3.反向解析路由配置
1.先給路由與檢視函式起一個別名
url(r'^func_kkk/',views.func,name='ooo') # name='ooo' 起別名
4.前後端反向解析
# 後端檢視函式反向解析
1.匯入模組reverse
from django.shortcuts import render,HttpResponse,redirect,reverse
2.反向解析 關鍵字 reverse('ooo')
def home(request):
print(reverse('ooo'))
return render(request,'home.html')
# 前端反向解析
3.前端模板檔案反向解析
<a href="{% url 'ooo' %}">111</a>
5.無名有名反向解析
1.當路由出現無名有名分組反向解析需要傳遞額外的引數
2.無名有名分組反向解析，目的就是需要給一個引數，如果有多個就是需要手動的給多個，這多個引數一般情況都是當前操作資料的主鍵值。
path('reg/<str:info>/', views.reg, name='reg_view')
當路由中有不確定的匹配因素 反向解析的時候需要人為給出一個具體的值
後端：
reverse('reg_view', args=('jason',))
前端：
{% url 'reg_view' 'jason' %}
ps:反向解析的操作三個方法都一樣path() re_path() url()