]> git.ipfire.org Git - thirdparty/fastapi/fastapi.git/commitdiff
✏ Fix incorrect Celery URLs in docs (#2100)
authorNutchanon Ninyawee <nutchanon@codustry.com>
Thu, 5 Nov 2020 22:02:07 +0000 (05:02 +0700)
committerGitHub <noreply@github.com>
Thu, 5 Nov 2020 22:02:07 +0000 (23:02 +0100)
docs/en/docs/tutorial/background-tasks.md
docs/en/docs/tutorial/sql-databases.md

index 107fe60c7b3ea7a5ad77a51ba852d311ea14e712..9b5e218e1529d9415566c92cbe538237fd050fdc 100644 (file)
@@ -81,7 +81,7 @@ You can see more details in <a href="https://www.starlette.io/background/" class
 
 ## Caveat
 
-If you need to perform heavy background computation and you don't necessarily need it to be run by the same process (for example, you don't need to share memory, variables, etc), you might benefit from using other bigger tools like <a href="http://www.celeryproject.org/" class="external-link" target="_blank">Celery</a>.
+If you need to perform heavy background computation and you don't necessarily need it to be run by the same process (for example, you don't need to share memory, variables, etc), you might benefit from using other bigger tools like <a href="https://docs.celeryproject.org/" class="external-link" target="_blank">Celery</a>.
 
 They tend to require more complex configurations, a message/job queue manager, like RabbitMQ or Redis, but they allow you to run background tasks in multiple processes, and especially, in multiple servers.
 
index 59eb6a4fb23dc2657dfabe4c1298df6893554324..05b2fee32650fba18b3f5be753f0927802fe1b29 100644 (file)
@@ -235,7 +235,7 @@ Now let's check the file `sql_app/schemas.py`.
     To avoid confusion between the SQLAlchemy *models* and the Pydantic *models*, we will have the file `models.py` with the SQLAlchemy models, and the file `schemas.py` with the Pydantic models.
 
     These Pydantic models define more or less a "schema" (a valid data shape).
-    
+
     So this will help us avoiding confusion while using both.
 
 ### Create initial Pydantic *models* / schemas
@@ -470,7 +470,7 @@ Our dependency will create a new SQLAlchemy `SessionLocal` that will be used in
     We put the creation of the `SessionLocal()` and handling of the requests in a `try` block.
 
     And then we close it in the `finally` block.
-    
+
     This way we make sure the database session is always closed after the request. Even if there was an exception while processing the request.
 
     But you can't raise another exception from the exit code (after `yield`). See more in [Dependencies with `yield` and `HTTPException`](./dependencies/dependencies-with-yield.md#dependencies-with-yield-and-httpexception){.internal-link target=_blank}
@@ -553,7 +553,7 @@ And as the code related to SQLAlchemy and the SQLAlchemy models lives in separat
 
 The same way, you would be able to use the same SQLAlchemy models and utilities in other parts of your code that are not related to **FastAPI**.
 
-For example, in a background task worker with <a href="http://www.celeryproject.org/" class="external-link" target="_blank">Celery</a>, <a href="https://python-rq.org/" class="external-link" target="_blank">RQ</a>, or <a href="https://arq-docs.helpmanual.io/" class="external-link" target="_blank">ARQ</a>.
+For example, in a background task worker with <a href="https://docs.celeryproject.org/" class="external-link" target="_blank">Celery</a>, <a href="https://python-rq.org/" class="external-link" target="_blank">RQ</a>, or <a href="https://arq-docs.helpmanual.io/" class="external-link" target="_blank">ARQ</a>.
 
 ## Review all the files
 
@@ -648,7 +648,7 @@ The middleware we'll add (just a function) will create a new SQLAlchemy `Session
     We put the creation of the `SessionLocal()` and handling of the requests in a `try` block.
 
     And then we close it in the `finally` block.
-    
+
     This way we make sure the database session is always closed after the request. Even if there was an exception while processing the request.
 
 ### About `request.state`