这种矩阵题现在第一反应就是用广度优先搜索做，类似之前算和0之间的距离那题。遍历矩阵，遇到 1 就将 1 改成 0，然后广度优先搜索找出 1 相邻的所有 1，这就是一个岛屿，以此类推。
\n1 | import collections |
200. 岛屿数量
","more":"这种矩阵题现在第一反应就是用广度优先搜索做，类似之前算和0之间的距离那题。遍历矩阵，遇到 1 就将 1 改成 0，然后广度优先搜索找出 1 相邻的所有 1，这就是一个岛屿，以此类推。
\n1 | import collections |
8. 字符串转换整数 (atoi)
\n\n没什么好说的，注意各种情况，识别到数字之后就一直要是数字。
\n1 | class Solution: |
8. 字符串转换整数 (atoi)
","more":"没什么好说的，注意各种情况，识别到数字之后就一直要是数字。
\n1 | class Solution: |
Partitioning refers to splitting what is logically one large table inot smaller physical pieces.
Currently, PostgreSQL supports partitioning via table inheritance. Each partition must be created as a child table of a single parent table. The parent table itself is normally empty; It exists just to represent the entire data set.
\nThere are two forms of partitioning can be implemented in PostgreSQL:
\n- \n
Range Partitioning
\n The table is partitioning into “range” defined by a key column or a set of columns, with no overlap between the ranges of values assigned to different partitions. eg. partition by date ranges or by identifiers.
\n \nList Partitioning
\n The table is partitioned by explicitly listing which key values appear in each partition.
\n \n
Implementing Partitioning
- \n
Create the “master” / “parent” table, from which all the partitions will inherit.
\n This table will not contain any data. Do not define any check on this table, unless you intend them to be applied equally to all partitions. There is no point in defining any indexes or unique constraints on it either.
\n \nCreate “child” tables that each inherit form the master table. Normally, these tables will not add any columns to the set inherited from the master.
\n \nAdd table constraints to the partition tables to define the allowed key values in each partitions.
\n Ensure that the constraints guarantee that there is no overlap between the key values premitted in different partitions. And there is no difference in syntax between range and list partitioning.
\n \nCreate indexes on column(s) for each partitions.
\n \nOptionally, define a trigger or rule to redirect data inserted into the master table to the appropriate partition.
\n \nEnsure hte constraint_exclusion configuration parameter is not disabled in
\npostgresql.conf. If it is, queries will not be optimized as desired. \n
Trigger
As we are creating new table and hopping data insered to right partition, a trigger function and a trigger are needed.
\n","site":{"data":{}},"excerpt":"","more":"Partitioning refers to splitting what is logically one large table inot smaller physical pieces.
Currently, PostgreSQL supports partitioning via table inheritance. Each partition must be created as a child table of a single parent table. The parent table itself is normally empty; It exists just to represent the entire data set.
\nThere are two forms of partitioning can be implemented in PostgreSQL:
\n- \n
Range Partitioning
\n The table is partitioning into “range” defined by a key column or a set of columns, with no overlap between the ranges of values assigned to different partitions. eg. partition by date ranges or by identifiers.
\n \nList Partitioning
\n The table is partitioned by explicitly listing which key values appear in each partition.
\n \n
Implementing Partitioning
- \n
Create the “master” / “parent” table, from which all the partitions will inherit.
\n This table will not contain any data. Do not define any check on this table, unless you intend them to be applied equally to all partitions. There is no point in defining any indexes or unique constraints on it either.
\n \nCreate “child” tables that each inherit form the master table. Normally, these tables will not add any columns to the set inherited from the master.
\n \nAdd table constraints to the partition tables to define the allowed key values in each partitions.
\n Ensure that the constraints guarantee that there is no overlap between the key values premitted in different partitions. And there is no difference in syntax between range and list partitioning.
\n \nCreate indexes on column(s) for each partitions.
\n \nOptionally, define a trigger or rule to redirect data inserted into the master table to the appropriate partition.
\n \nEnsure hte constraint_exclusion configuration parameter is not disabled in
\npostgresql.conf. If it is, queries will not be optimized as desired. \n
Trigger
As we are creating new table and hopping data insered to right partition, a trigger function and a trigger are needed.
\n"},{"title":"Django Manager Method","date":"2016-04-24T16:00:01.000Z","_content":"\n\n\n#### Django Manager\n\nDjango 里会为每一个 model 生成一个 Manager，默认名字为 objects，一般情况下对 model 进行的处理都是通过 model.objects.XXX( ) 来进行的。其实是调用了 model 的 manager 的方法，而 manager 之中的方法是 QuerySet 方法的代理，QuerySet 方法是对数据库操作的封装。\n\neg.\n\n```python\nfrom django.db import models\n\nclass Person(models.Model):\n\t...\n\tpeople = models.Manager()\n```\n\n上面这个 model，`Person.objects`会产生一个`AttributeError`，但是`Person.people`就可以正常操作。因为默认的 manager 已经变成 people，objects 这个 manager 没有重新声明，不起作用。\n\n#### 自定义 Manager\n\n通常需要自定义 manager 的情况有两点:\n\n1. 需要修改/扩展 Django 的 manager 方法\n2. 需要修改返回的 QuerySet\n\n#### 默认 Manager\n\n如果使用自定义的 manager 需要注意的是，Django 将 model 中定义的第一个 manager 认为是默认 manager，而且 Django 框架中会用到默认 manager。\n\n笨方法是使用自定义 manager 的时候，对于 model 依然提供 objects 这个默认 manager，并放在第一个。\n\neg.\n\n```python\nclass Book(models.Model):\n\ttitle = models.CharField(max_length=100)\n\tauthor = models.CharField(max_length=50)\n\t\n\tobjects = models.Manager() # default manager\n\tcustom_objects = CustomBOokManager() # custom manager\n```\n\n\n\n[source](http://blog.csdn.net/sicofield/article/details/49283751)\n\n\n\n","source":"_posts/Django-Manager-Method.md","raw":"---\ntitle: Django Manager Method\ndate: 2016-04-25 00:00:01\n---\n\n\n\n#### Django Manager\n\nDjango 里会为每一个 model 生成一个 Manager，默认名字为 objects，一般情况下对 model 进行的处理都是通过 model.objects.XXX( ) 来进行的。其实是调用了 model 的 manager 的方法，而 manager 之中的方法是 QuerySet 方法的代理，QuerySet 方法是对数据库操作的封装。\n\neg.\n\n```python\nfrom django.db import models\n\nclass Person(models.Model):\n\t...\n\tpeople = models.Manager()\n```\n\n上面这个 model，`Person.objects`会产生一个`AttributeError`，但是`Person.people`就可以正常操作。因为默认的 manager 已经变成 people，objects 这个 manager 没有重新声明，不起作用。\n\n#### 自定义 Manager\n\n通常需要自定义 manager 的情况有两点:\n\n1. 需要修改/扩展 Django 的 manager 方法\n2. 需要修改返回的 QuerySet\n\n#### 默认 Manager\n\n如果使用自定义的 manager 需要注意的是，Django 将 model 中定义的第一个 manager 认为是默认 manager，而且 Django 框架中会用到默认 manager。\n\n笨方法是使用自定义 manager 的时候，对于 model 依然提供 objects 这个默认 manager，并放在第一个。\n\neg.\n\n```python\nclass Book(models.Model):\n\ttitle = models.CharField(max_length=100)\n\tauthor = models.CharField(max_length=50)\n\t\n\tobjects = models.Manager() # default manager\n\tcustom_objects = CustomBOokManager() # custom manager\n```\n\n\n\n[source](http://blog.csdn.net/sicofield/article/details/49283751)\n\n\n\n","slug":"Django-Manager-Method","published":1,"updated":"2018-05-15T14:58:35.000Z","comments":1,"layout":"post","photos":[],"link":"","_id":"ck99fqk52001bsubuwh45f7em","content":"Django Manager
Django 里会为每一个 model 生成一个 Manager，默认名字为 objects，一般情况下对 model 进行的处理都是通过 model.objects.XXX( ) 来进行的。其实是调用了 model 的 manager 的方法，而 manager 之中的方法是 QuerySet 方法的代理，QuerySet 方法是对数据库操作的封装。
\neg.
\n1 | from django.db import models |
上面这个 model，Person.objects会产生一个AttributeError，但是Person.people就可以正常操作。因为默认的 manager 已经变成 people，objects 这个 manager 没有重新声明，不起作用。
自定义 Manager
通常需要自定义 manager 的情况有两点:
\n- \n
- 需要修改/扩展 Django 的 manager 方法 \n
- 需要修改返回的 QuerySet \n
默认 Manager
如果使用自定义的 manager 需要注意的是，Django 将 model 中定义的第一个 manager 认为是默认 manager，而且 Django 框架中会用到默认 manager。
\n笨方法是使用自定义 manager 的时候，对于 model 依然提供 objects 这个默认 manager，并放在第一个。
\neg.
\n1 | class Book(models.Model): |
Django Manager
Django 里会为每一个 model 生成一个 Manager，默认名字为 objects，一般情况下对 model 进行的处理都是通过 model.objects.XXX( ) 来进行的。其实是调用了 model 的 manager 的方法，而 manager 之中的方法是 QuerySet 方法的代理，QuerySet 方法是对数据库操作的封装。
\neg.
\n1 | from django.db import models |
上面这个 model，Person.objects会产生一个AttributeError，但是Person.people就可以正常操作。因为默认的 manager 已经变成 people，objects 这个 manager 没有重新声明，不起作用。
自定义 Manager
通常需要自定义 manager 的情况有两点:
\n- \n
- 需要修改/扩展 Django 的 manager 方法 \n
- 需要修改返回的 QuerySet \n
默认 Manager
如果使用自定义的 manager 需要注意的是，Django 将 model 中定义的第一个 manager 认为是默认 manager，而且 Django 框架中会用到默认 manager。
\n笨方法是使用自定义 manager 的时候，对于 model 依然提供 objects 这个默认 manager，并放在第一个。
\neg.
\n1 | class Book(models.Model): |
Hello, {{ user.nickname }}!
\n \n \n\n```\n\nNow let's write the view function that uses this template (file `app/views.py`):\n\n``` python\nfrom flask import render_template\nfrom app import app\n\n@app.route('/')\n@app.route('/index')\ndef index():\n user = {'nickname': 'ching'} # fake user\n return render_template('index.html',\n title='Home',\n user=user)\n```\n\n`render_template` function is what we import from Flask framework to render the template. It uses [Jinja2](http://jinja.pocoo.org/) templating engine.\n\n","source":"_posts/Flask-Day-1.md","raw":"---\ntitle: Flask Day 1\ndate: 2016-02-15 01:23:33\n---\n\n### \"Hello World\" in Flask\n\nCreate a folder named `microblog` (or whatever you want). Then cd into that folder and run following prompt in terminal:\n\n``` bash\n$ python3 -m venv flask\n```\n\nNow you'll have a folder named `flask` inside `microblog`, containing a private version of Python interpreter.\n\nAnd you should install **flask** and extensions by the commands below:\n\n``` bash\n$ flask/bin/pip install flask\n$ flask/bin/pip install flask-login\n$ flask/bin/pip install flask-openid\n$ flask/bin/pip install flask-mail\n$ flask/bin/pip install flask-sqlalchemy\n$ flask/bin/pip install sqlalchemy-migrate\n$ flask/bin/pip install flask-whooshalchemy\n$ flask/bin/pip install flask-wtf\n$ flask/bin/pip install flask-babel\n$ flask/bin/pip install guess_language\n$ flask/bin/pip install flipflop\n$ flask/bin/pip install coverage\n```\n\nAfter that, let's create the basic structure for our application: `app` `app/static` `app/templates` `tmp`.\n\n1. `app` — where the application package is\n2. `static` — stores static files like images, javascripts, and css.\n3. `templates` — where templates will go.\n\nThen you can start with ``__init__.py`` which should put into app folder (file `app/__init__.py`):\n\n``` python\nfrom flask import Flask\n\napp = Flask(__name__)\nfrom app import views\n```\n\nThe views are the handlers that response to requests from web browsers or other clients. Each view function is mapped to one or more request URLs.\n\nLet's see what a views function looks like (file `app/views.py`):\n\n``` python\nfrom flask import Flask\n\napp = Flask(__name__)\nfrom app import views\n```\n\nFinally we should create a script to starts up the web server with our application(file `run.py`):\n\n``` python\n#!flask/bin/python\nfrom app import app\napp.run(debug=True)\n```\n\nTo indicating that is an executable file you need to run this in terminal:\n\n``` bash\n$ chmod a+x run.py\n```\n\nNow the file structure should look like:\n\n``` \n microblog\\\n flask\\\nHello, {{ user.nickname }}!
\n \n \n\n```\n\nNow let's write the view function that uses this template (file `app/views.py`):\n\n``` python\nfrom flask import render_template\nfrom app import app\n\n@app.route('/')\n@app.route('/index')\ndef index():\n user = {'nickname': 'ching'} # fake user\n return render_template('index.html',\n title='Home',\n user=user)\n```\n\n`render_template` function is what we import from Flask framework to render the template. It uses [Jinja2](http://jinja.pocoo.org/) templating engine.\n\n","slug":"Flask-Day-1","published":1,"updated":"2018-05-15T14:58:35.000Z","comments":1,"layout":"post","photos":[],"link":"","_id":"ck99fqk52001dsubuwkxumfmo","content":"“Hello World” in Flask
Create a folder named microblog (or whatever you want). Then cd into that folder and run following prompt in terminal:
1 | $ python3 -m venv flask |
Now you’ll have a folder named flask inside microblog, containing a private version of Python interpreter.
And you should install flask and extensions by the commands below:
\n1 | $ flask/bin/pip install flask |
After that, let’s create the basic structure for our application: app app/static app/templates tmp.
- \n
app— where the application package is \nstatic— stores static files like images, javascripts, and css. \ntemplates— where templates will go. \n
Then you can start with __init__.py which should put into app folder (file app/__init__.py):
1 | from flask import Flask |
The views are the handlers that response to requests from web browsers or other clients. Each view function is mapped to one or more request URLs.
\nLet’s see what a views function looks like (file app/views.py):
1 | from flask import Flask |
Finally we should create a script to starts up the web server with our application(file run.py):
1 | #!flask/bin/python |
To indicating that is an executable file you need to run this in terminal:
\n1 | $ chmod a+x run.py |
Now the file structure should look like:
\n1 | microblog\\ |
Then start to write the template (file app/templates/index.html):
1 | <html> |
Now let’s write the view function that uses this template (file app/views.py):
1 | from flask import render_template |
render_template function is what we import from Flask framework to render the template. It uses Jinja2 templating engine.
“Hello World” in Flask
Create a folder named microblog (or whatever you want). Then cd into that folder and run following prompt in terminal:
1 | $ python3 -m venv flask |
Now you’ll have a folder named flask inside microblog, containing a private version of Python interpreter.
And you should install flask and extensions by the commands below:
\n1 | $ flask/bin/pip install flask |
After that, let’s create the basic structure for our application: app app/static app/templates tmp.
- \n
app— where the application package is \nstatic— stores static files like images, javascripts, and css. \ntemplates— where templates will go. \n
Then you can start with __init__.py which should put into app folder (file app/__init__.py):
1 | from flask import Flask |
The views are the handlers that response to requests from web browsers or other clients. Each view function is mapped to one or more request URLs.
\nLet’s see what a views function looks like (file app/views.py):
1 | from flask import Flask |
Finally we should create a script to starts up the web server with our application(file run.py):
1 | #!flask/bin/python |
To indicating that is an executable file you need to run this in terminal:
\n1 | $ chmod a+x run.py |
Now the file structure should look like:
\n1 | microblog\\ |
Then start to write the template (file app/templates/index.html):
1 | <html> |
Now let’s write the view function that uses this template (file app/views.py):
1 | from flask import render_template |
render_template function is what we import from Flask framework to render the template. It uses Jinja2 templating engine.
Sign In
\n \n{% endblock %}\n```\n\n\n\nThe final step is to code a view function that renders the template and receiving data from form (file `app/views.py`):\n\n``` python\nfrom flask import render_template, flash, redirect\nfrom app import app\nfrom .forms import LoginForm\n\n# index view function suppressed for brevity\n\napp.route('/login', methods=['GET', 'POST'])\ndef login():\n form = LoginForm()\n if form.validate_on_submit():\n flash('Login requested for OpenID=\"%s\", remember_me=%s' %\n (form.openid.data, str(form.remember_me.data)))\n return redirect('/index')\n return render_template('login.html', \n title='Sign In',\n form=form)\n```\n\n","source":"_posts/Flask-Day-2.md","raw":"---\ntitle: Flask Day 2\ndate: 2016-02-16 22:45:06\n---\n\nTo handle web forms we use [Flask-WTF\t](http://packages.python.org/Flask-WTF). So we need to write a config file (file `config.py`):\n\n``` python\nWTF_CSRF_ENABLED = True\nSECRET_KEY = 'you-will-never-guess'\n```\n\nAnd then you need to use this config (file `app/__init__.py`):\n\n``` python\nfrom flask import Flask\n\napp = Flask(__name__)\napp.config.from_object('config')\n\nfrom app import views\n```\n\nLet's build a simple form (file `app/forms.app`):\n\n``` python\nfrom flask.ext.wtf import Form\nfrom wtforms import StringField, BooleanField\nfrom wtforms.validators import DataRequired\n\nclass LoginForm(Form):\n openid = StringField('openid', validators=[DataRequired()])\n remember_me = BooleanField('remember_me', default=False)\n```\n\nThe `DataRequired()` is a validator that checks the field is empty or not.\n\nAfter that, we need a HTML page to show the form (file `app/templates/login.html`):\n\n``` html\n\n{% extends \"base.html\" %}\n\n{% block content %}\nSign In
\n \n{% endblock %}\n```\n\n\n\nThe final step is to code a view function that renders the template and receiving data from form (file `app/views.py`):\n\n``` python\nfrom flask import render_template, flash, redirect\nfrom app import app\nfrom .forms import LoginForm\n\n# index view function suppressed for brevity\n\napp.route('/login', methods=['GET', 'POST'])\ndef login():\n form = LoginForm()\n if form.validate_on_submit():\n flash('Login requested for OpenID=\"%s\", remember_me=%s' %\n (form.openid.data, str(form.remember_me.data)))\n return redirect('/index')\n return render_template('login.html', \n title='Sign In',\n form=form)\n```\n\n","slug":"Flask-Day-2","published":1,"updated":"2018-05-15T14:58:35.000Z","comments":1,"layout":"post","photos":[],"link":"","_id":"ck99fqk53001fsubukfg8z46w","content":"To handle web forms we use Flask-WTF . So we need to write a config file (file config.py):
1 | WTF_CSRF_ENABLED = True |
And then you need to use this config (file app/__init__.py):
1 | from flask import Flask |
Let’s build a simple form (file app/forms.app):
1 | from flask.ext.wtf import Form |
The DataRequired() is a validator that checks the field is empty or not.
After that, we need a HTML page to show the form (file app/templates/login.html):
1 | <!-- extend from base layout --> |
The final step is to code a view function that renders the template and receiving data from form (file app/views.py):
1 | from flask import render_template, flash, redirect |
To handle web forms we use Flask-WTF . So we need to write a config file (file config.py):
1 | WTF_CSRF_ENABLED = True |
And then you need to use this config (file app/__init__.py):
1 | from flask import Flask |
Let’s build a simple form (file app/forms.app):
1 | from flask.ext.wtf import Form |
The DataRequired() is a validator that checks the field is empty or not.
After that, we need a HTML page to show the form (file app/templates/login.html):
1 | <!-- extend from base layout --> |
The final step is to code a view function that renders the template and receiving data from form (file app/views.py):
1 | from flask import render_template, flash, redirect |
Resources in Tastypie
Resources are the heart of Tastypie. By defining a resource we can actually convert a model into an API stream. The data is automatically converted into API response.
\nUnderstanding the process of creating a resource.
\n- \n
- Import ModelResource from Tastypie. \n
- Import models from services app \n
- Create custom resource by inheriting ModelResource and link app model in inner Meta class of resource. \n
Add API URL in the urls.py of app.
\nDehydrating the JSON data
![\"flow\"](\"https://impythonist.files.wordpress.com/2016/04/tastypie_ill.png?w=800\")
Dehydration in Tastypie means making alterations before sending data to the client. Suppose we need to send capitalized product names instead of small letters. Now we see two kinds of dehydrate methods.
\nDehydrate_field method
This dehydrate_field is uesd to modify field on the response JSON.
Dehydrate method
Dehydrate method is useful for aadding additional fields to bundle (response data).
\nSimilarly using hydrate method we can alter the bundle data which is generated from request at the time of PUT or POST methods.
Resources in Tastypie
Resources are the heart of Tastypie. By defining a resource we can actually convert a model into an API stream. The data is automatically converted into API response.
\nUnderstanding the process of creating a resource.
\n- \n
- Import ModelResource from Tastypie. \n
- Import models from services app \n
- Create custom resource by inheriting ModelResource and link app model in inner Meta class of resource. \n
Add API URL in the urls.py of app.
\nDehydrating the JSON data
Dehydration in Tastypie means making alterations before sending data to the client. Suppose we need to send capitalized product names instead of small letters. Now we see two kinds of dehydrate methods.
\nDehydrate_field method
This dehydrate_field is uesd to modify field on the response JSON.
Dehydrate method
Dehydrate method is useful for aadding additional fields to bundle (response data).
\nSimilarly using hydrate method we can alter the bundle data which is generated from request at the time of PUT or POST methods.
This is the very first post I wrote,
\n\n","site":{"data":{}},"excerpt":"","more":"This is the very first post I wrote,
\n\n"},{"title":"TastyPie Note 1","date":"2016-05-10T09:00:00.000Z","_content":"\n### Flow Through The Request/Response Cycle\n\nTastypie can be thought of as a set of class-based view that provide the API functionality. All routing/middleware/response-handling aspectss are the same as a typical Django app. Where the differs is in the view itself.\n\nWalking through what a GET request to a list endpoint looks like:\n\n- The `Resource.urls` are checked by Django's url resolvers.\n\n- On a match for the list view, `Resource.wrap_view('dispatch_list')` is called. `wrap_view` provides basic error handling & allows for returning serilized errors.\n\n- Because dispatch_list was passed to `wrap_view`, `Resource.dispatch_list` is called next. This is a thin wrapper around `Resource.dispatch`.\n\n- `dispatch` does a bunch of havy lifting. It ensures:\n\n - the requested HTTP method is in `allowed_methos` (`method_check`).\n - the class has a method that can handle the request(`get_list`)\n - the user is authenticated(`is_authenticated`)\n - the user has no exceeded their throttle(`throttle_check`).\n\n At this point, `dispatch` actually calls the requested method (`get_list`).\n\n- `get_list` does the actual work of API. It does:\n\n - A fetch of the available objects via `Resource.obj_get_list`. In the case of `ModelResource`, this builds the ORM filters to apply (`ModelResource.build_filters`). It then gets the `QuerySet` via `ModelResource.get_object_list` (which performs `Resource.authorized_read_list` to possibly limit the set the user can work with) and applies the built filters to it.\n - It then sorts the objects based on user input (`ModelResource.apply_sorting`).\n - Then it paginates the results using the supplied `Paginator` & pulls out the data to be serialized.\n - The objects in the page have `full_dehydrate` applied to each of them, causing Tastypie to traslate the raw object data into the fields the endpoint supports.\n - Finally, it calls `Resource.create_response`.\n\n- `create_response` is a shortcut method that:\n\n - Determines the desired response format (`Resource.determine_format`).\n - Serializes the data given to it in the proper format.\n - Returns a Django `HttpResponse` (200 OK) with the serialized data.\n\n- We bubble back up the call stack to `dispatch`. The last thing `dispatch` does is potentially store that a request occured for future throttling (`Resource.log_throttled_access`) then either returns the `HttpResponse` or wraps whatever data came back in a response (so Django doesn't freak out).\n\n\n\n","source":"_posts/TastyPie-Note-1.md","raw":"---\ntitle: TastyPie Note 1\ndate: 2016-05-10 17:00:00\n---\n\n### Flow Through The Request/Response Cycle\n\nTastypie can be thought of as a set of class-based view that provide the API functionality. All routing/middleware/response-handling aspectss are the same as a typical Django app. Where the differs is in the view itself.\n\nWalking through what a GET request to a list endpoint looks like:\n\n- The `Resource.urls` are checked by Django's url resolvers.\n\n- On a match for the list view, `Resource.wrap_view('dispatch_list')` is called. `wrap_view` provides basic error handling & allows for returning serilized errors.\n\n- Because dispatch_list was passed to `wrap_view`, `Resource.dispatch_list` is called next. This is a thin wrapper around `Resource.dispatch`.\n\n- `dispatch` does a bunch of havy lifting. It ensures:\n\n - the requested HTTP method is in `allowed_methos` (`method_check`).\n - the class has a method that can handle the request(`get_list`)\n - the user is authenticated(`is_authenticated`)\n - the user has no exceeded their throttle(`throttle_check`).\n\n At this point, `dispatch` actually calls the requested method (`get_list`).\n\n- `get_list` does the actual work of API. It does:\n\n - A fetch of the available objects via `Resource.obj_get_list`. In the case of `ModelResource`, this builds the ORM filters to apply (`ModelResource.build_filters`). It then gets the `QuerySet` via `ModelResource.get_object_list` (which performs `Resource.authorized_read_list` to possibly limit the set the user can work with) and applies the built filters to it.\n - It then sorts the objects based on user input (`ModelResource.apply_sorting`).\n - Then it paginates the results using the supplied `Paginator` & pulls out the data to be serialized.\n - The objects in the page have `full_dehydrate` applied to each of them, causing Tastypie to traslate the raw object data into the fields the endpoint supports.\n - Finally, it calls `Resource.create_response`.\n\n- `create_response` is a shortcut method that:\n\n - Determines the desired response format (`Resource.determine_format`).\n - Serializes the data given to it in the proper format.\n - Returns a Django `HttpResponse` (200 OK) with the serialized data.\n\n- We bubble back up the call stack to `dispatch`. The last thing `dispatch` does is potentially store that a request occured for future throttling (`Resource.log_throttled_access`) then either returns the `HttpResponse` or wraps whatever data came back in a response (so Django doesn't freak out).\n\n\n\n","slug":"TastyPie-Note-1","published":1,"updated":"2018-05-15T14:58:35.000Z","comments":1,"layout":"post","photos":[],"link":"","_id":"ck99fqk55001jsubuwea2oyll","content":"Flow Through The Request/Response Cycle
Tastypie can be thought of as a set of class-based view that provide the API functionality. All routing/middleware/response-handling aspectss are the same as a typical Django app. Where the differs is in the view itself.
\nWalking through what a GET request to a list endpoint looks like:
\n- \n
The
\nResource.urlsare checked by Django’s url resolvers. \nOn a match for the list view,
\nResource.wrap_view('dispatch_list')is called.wrap_viewprovides basic error handling & allows for returning serilized errors. \nBecause dispatch_list was passed to
\nwrap_view,Resource.dispatch_listis called next. This is a thin wrapper aroundResource.dispatch. \n
\ndispatchdoes a bunch of havy lifting. It ensures:- \n
- the requested HTTP method is in
allowed_methos(method_check). \n - the class has a method that can handle the request(
get_list) \n - the user is authenticated(
is_authenticated) \n - the user has no exceeded their throttle(
throttle_check). \n
At this point,
\ndispatchactually calls the requested method (get_list). \n- the requested HTTP method is in
\nget_listdoes the actual work of API. It does:- \n
- A fetch of the available objects via
Resource.obj_get_list. In the case ofModelResource, this builds the ORM filters to apply (ModelResource.build_filters). It then gets theQuerySetviaModelResource.get_object_list(which performsResource.authorized_read_listto possibly limit the set the user can work with) and applies the built filters to it. \n - It then sorts the objects based on user input (
ModelResource.apply_sorting). \n - Then it paginates the results using the supplied
Paginator& pulls out the data to be serialized. \n - The objects in the page have
full_dehydrateapplied to each of them, causing Tastypie to traslate the raw object data into the fields the endpoint supports. \n - Finally, it calls
Resource.create_response. \n
\n- A fetch of the available objects via
\ncreate_responseis a shortcut method that:- \n
- Determines the desired response format (
Resource.determine_format). \n - Serializes the data given to it in the proper format. \n
- Returns a Django
HttpResponse(200 OK) with the serialized data. \n
\n- Determines the desired response format (
We bubble back up the call stack to
\ndispatch. The last thingdispatchdoes is potentially store that a request occured for future throttling (Resource.log_throttled_access) then either returns theHttpResponseor wraps whatever data came back in a response (so Django doesn’t freak out). \n
Flow Through The Request/Response Cycle
Tastypie can be thought of as a set of class-based view that provide the API functionality. All routing/middleware/response-handling aspectss are the same as a typical Django app. Where the differs is in the view itself.
\nWalking through what a GET request to a list endpoint looks like:
\n- \n
The
\nResource.urlsare checked by Django’s url resolvers. \nOn a match for the list view,
\nResource.wrap_view('dispatch_list')is called.wrap_viewprovides basic error handling & allows for returning serilized errors. \nBecause dispatch_list was passed to
\nwrap_view,Resource.dispatch_listis called next. This is a thin wrapper aroundResource.dispatch. \n
\ndispatchdoes a bunch of havy lifting. It ensures:- \n
- the requested HTTP method is in
allowed_methos(method_check). \n - the class has a method that can handle the request(
get_list) \n - the user is authenticated(
is_authenticated) \n - the user has no exceeded their throttle(
throttle_check). \n
At this point,
\ndispatchactually calls the requested method (get_list). \n- the requested HTTP method is in
\nget_listdoes the actual work of API. It does:- \n
- A fetch of the available objects via
Resource.obj_get_list. In the case ofModelResource, this builds the ORM filters to apply (ModelResource.build_filters). It then gets theQuerySetviaModelResource.get_object_list(which performsResource.authorized_read_listto possibly limit the set the user can work with) and applies the built filters to it. \n - It then sorts the objects based on user input (
ModelResource.apply_sorting). \n - Then it paginates the results using the supplied
Paginator& pulls out the data to be serialized. \n - The objects in the page have
full_dehydrateapplied to each of them, causing Tastypie to traslate the raw object data into the fields the endpoint supports. \n - Finally, it calls
Resource.create_response. \n
\n- A fetch of the available objects via
\ncreate_responseis a shortcut method that:- \n
- Determines the desired response format (
Resource.determine_format). \n - Serializes the data given to it in the proper format. \n
- Returns a Django
HttpResponse(200 OK) with the serialized data. \n
\n- Determines the desired response format (
We bubble back up the call stack to
\ndispatch. The last thingdispatchdoes is potentially store that a request occured for future throttling (Resource.log_throttled_access) then either returns theHttpResponseor wraps whatever data came back in a response (so Django doesn’t freak out). \n