[Django 공식문서 번역] Models - 6. Database transactions

이 글은 본인이 공부를 목적으로 공식문서를 읽으며 정리/번역한 글로서 오역이 있을 수 있을 수 있습니다. 또한 본인이 이미 알고 있거나 불필요하다 느끼는 내용들은 누락될 수 있습니다.

Database Transactions

장고는 기본적으로 autocommit mode로 작동한다. 각각의 query는 trasaction이 active하지 않은 이상 바로바로 commit 된다.

- Commit은 모든 작업을 정상적으로 처리하겠다고 확정하는 명령어로써 트랜젝션의 처리과정을 데이터베이스에 영구적으로 저장한다.
- Rollback은 작업중 문제가 발생했을 때, 트랜젝션의 처리과정에서 발생한 변경사항을 취소하고 트랜젝션의 과정을 종료시킨다. 트랜젝션으로 인한 하나의 묶음처리가 시작되기 이전의 상태로 되돌린다.

Tying transactions to HTTP requests

일반적으로 transaction을 web에서 처리하는 방법은 각각의 request를 trascation으로 합치는 것이다. ATOMIC_REQUESTS를 True로 하면 이렇게 작동시킬 수 있다.

장고는 view function를 호출하기전 transaction을 시작한다. 만약 문제없이 response가 나왔다면 장고는 transaction을 commit한다. 만약 view가 exception을 발생시기면 장고는 transaction을 rollback한다.

atomic() context manager를 사용하여 subtransaction들을 수행할 수 있지만 view가 끝날때 모든 변경사항들이 반영되거나 하나도 반영되지 않는다.
























댓글

댓글 쓰기

이 블로그의 인기 게시물

[Django REST Framework] create() vs perform_create()

Django REST Framework의 ModelViewSet과 create() 관련 찾아보고 공부한 내용을 정리해보려고 한다. 기본적으로 ModelViewSet은 GenericAPIView라는 클래스를 상속받기 때문에 .list(), .create()  .list(), .create() 등을 기본으로 내장하고 있다. 따라서 이 중에서 기본 내장되어 있는 메소드 중 동작을 변경하고 싶은 것들만 overriding해서 수정하면 된다. 그리고 ModelViewSet은 GenericAPIView를 상속받고 있기 때문에 최소한 queryset와 serializer_class는 세팅해주어야 한다. from rest_framework import status from rest_framework.response import Response def create(self, request, *args, **kwargs): serializer = self.get_serializer(data=request.data) serializer.is_valid(raise_exception=True) self.perform_create(serializer) headers = self.get_success_headers(serializer.data) return Response(serializer.data, status=status.HTTP_201_CREATED, headers=headers) def perform_create(self, serializer): serializer.save() 위의 코드를 보면 이해가 조금 더 쉬울 것 같다. perform_create()은 create()의 동작 중 일부분을 overriding한다고 생각하면 되는데, serializer.save()가 호출될 때 perform_create()가 호출된다고 생각하면 된다. 위의 경우 명시적으로 perform_create()를 호출했지...
자세한 내용 보기

[웹 보안] CORS란?

원문:  https://dev.to/nicolus/what-you-should-know-about-cors-48d6 CORS는 Cross-Origin Resource Sharing의 줄임말이다.  처음배우는 사람들에게는 CORS가 무엇때문에 사용되는지 헷갈릴때가 많다. 첫째로, CORS는 보안을 강화하기 위한 수단이 아니다. 사실 그의 정반대이다. CORS는 Same Origin Policy(Browser의 정책중 하나로 document나 script가 다른 domain과 교신하는 것을 막는다)를 피하기위함이다. Same Origin Policy는 하나의 도메인에서 다른 도메인으로 요청하는 것을 막는다. 이렇게 하면 악성 웹사이트들이 다른 웹사이트들에게 요청보내는 것을 막을 수 있다. 이 정책은 브라우저에 적용되어 있기때문에 서버에서 보낸 요청이나 다른 HTTP 클라이언트(cURL / POSTman 등)에게는 적용되지 않는다. 서버는 이 요청들을 신뢰할 수 있는 도메인에서 보낸 요청이라고 생각하고 처리할 수 밖에 없다.  SOP(Same Origin Policy)는 공격자가 요청을 보내는 것을 막기 위한 수단이 아니다(공격자들은 브라우저를 사용하지 않을 것이다..). SOP는 단지 정당한 사용자들이 본인도 모르게 보내는 요청들을 걸러주는 역할을 한다. 그래서 CORS는 일반적으로 SOP에 의해 막힐요청을 화이트리스트에 등록해 허용해주는 역할을 한다(예를 들자면 front-end app이 API에 요청을 보내는 것)
자세한 내용 보기

3. GRAPHQL FRAGMENTS

# Why do we need Fragments? Fragments are used to reduce redundancy. You can think of it as something like struct in C. For exmaple, ``` query {   Lift(id: "jazz-cat") {     name     status     capacity     night     elevationGain     trailAccess {       name       difficulty     } }   Trail(id: "river-run"){     name     difficulty     accessedByLifts {       name       status       capacity       night       elevationGain ...
자세한 내용 보기