장고 마이그레이션시 기존테이블이 있을경우

|

기존db가 있을경우 마이그레이션
python manage.py makemigrations <app>
python manage.py migrate --fake <app> zero
python manage.py migrate --fake-initial <app>

확인
python manage.py showmigrations

 

 

참고사이트

https://cocook.tistory.com/64

And

composer 각종오류시....

|

composer clearcache

 

후에

composer update -vvv

 

 

And

mysql root 패스워드 없이 접속될때

|

mysql user테이블에 root유저 필드를 보면 plugin이 있다 unix_socket로 되어있으면 패스워드없이 들어가진다

 

UPDATE mysql.user SET plugin = '' WHERE user = 'root' AND host = 'localhost';

FLUSH PRIVILEGES;

위와같이 없애면 잘 된다

And

외래키 제약조건 무시하기

|

외래키 무시

SET foreign_key_checks = 0;

 

작업 후

 

SET foreign_key_checks = 1;

 

돌려놓기

And

시놀로지 volumio nfs셋팅시

|

https://volumio.github.io/docs/Good_to_Knows/Mounting_an_NFS_Share

 

Mounting an NFS Share - Volumio Documentation

Adding Music from a shared folder on a Synology tested on Synology DS412 in combination with Volumio 0.978 for Raspberry Pi 3 Since both Synology and Volumio for Raspberry PI are Unix based the preference is to use NFS type file sharing. For more informati

volumio.github.io

 

공유폴더 설정에서 nfs 설정을 해줘야 한다

 

And

nas 시놀로지 초기화 후 ssh접속 안될경우

|

ssh-keygen -R [192.168.1.xxx]:port

 

시놀로지 초기화 후 같은ip를 사용하여 접속하려고 하는데 RSA공유키 충돌문제로 접속이 되지 않았다

구글링해보면 ssh-keygen -R 192.168.1.xxx까지만 나와있다

하지만 위처럼 하면 되지 않았다

위에 [ip]:port로 적어 준 후 다시 키가 생성되었다

 

And

crontab으로 docker실행시 -i플래그 제거 (시놀로지 팁)

|

시놀로지에서 도커 운영중 ubuntu에서 supervisor을 실행해야하는데 도커가 재부팅시마다 supervisor이 실행이 되지않아

시놀로지에서 sudo vi /etc/crontab

docker exec 이미지명 supervisord -c /etc/supervisor/supervisord.conf

와 같이 추가하고 sudo synoservicectl --restart crond 으로 리스타트 해주면 된다

평소처럼 아무생각없이 -it옵션을줘서 실행이 되지 않아 몇일을 헤멨다... ㅠ


실제 서버에서 dockderfile이나 docker-compose를 만들어서 부팅시 실행하게 해주면 되지만 시놀로지 docker운영에선 이것들이 되지 않는다...

이미지를 만들어 docker에 올려 내려받음 되지만... 귀찮으므로...  

And

오류처리 Exception 'yii\db\Exception' with message 'Error while sending QUERY packet.

|

  1 [mysqld]

  2 max_allowed_packet=524288000

  3

  4 skip-external-locking

  5 key_buffer_size = 512M

  6 max_allowed_packet = 16M

  7 table_open_cache = 512

  8 sort_buffer_size = 2M

  9 read_buffer_size = 2M

 10 read_rnd_buffer_size = 8M

 11 myisam_sort_buffer_size = 64M

 12 thread_cache_size = 8

 13 query_cache_size = 64M

 14 thread_concurrency = 8

 15 server-id = 1162

 16 binlog_format=mixed

 17 expire_logs_days = 5

 18 user = mysql

 19 skip_name_resolve

 20 log-warnings = 2

 21 slow_query_log

 22 long_query_time = 1

 23 open_files_limit = 2048

 24 skip_slave_start

 25 slave-skip-errors = all

 26 max_heap_table_size = 1G

 27 wait_timeout = 28800



max_allowed_packet=524288000

wait_timeout = 28800


2가지 옵션을 줘본다.


And

model migrate 하기

|


모델 생성

python manage.py makemigrations <appname>

-> create,update,delete등의 변경사항을 migration으로 저장 및 django에 알림

-> 디스크상의 파일로 존재 appname/migrations/0001_initial.py


위의 쿼리를 보고 싶다면?

python manage.py sqlmigrate <appname> 0001

-> 위 숫자는 해당 디렉토리가서 확인하기


실행하기

python manage.py migrate <appname> <위의 숫자>

-> appname, 숫자등은 생략 가능



위의 과정중 오류가 나면 ?

python manage.py migrate --fake <appname>


절대 DB에 들어가 쿼리조작하지말것, 해당앱 migrations 디렉토리가서 파일 삭제하지말것

위 --fake옵션으로 거의 해결가능함






참고자료 : https://docs.djangoproject.com/ko/2.0/intro/tutorial02/



테이블 꼬였을경우 다시 처음부터.... ?





05) 마이그레이션 파일 제거

마이그레이션 파일 제거

Django 마이그레이션 도구는 모델 관리에 훌륭한 도구이다 그러나 너무 많이 저장소에서 관리하는 것이 때로는 불필요한 문제나 부작용을 일으키기도 한다. 그래서 가끔은 마이그레이션 파일을 정리하는 것이 좋다.

첫 번째 시나리오

아직 전혀 배포되지 않은 개발 중인 프로젝트는 중간 중간에 마이그레이션을 싹 지우는 것도 좋다.

마이그레이션 디렉토리 안에 모든 파일을 __init__.py 모듈 빼고 싹 지운다. 리눅스에서는 아래와 같은 명령어로 쉽게 지울 수 있다.

find . -path "*/migrations/*.py" -not -name "__init__.py" -delete
find . -path "*/migrations/*.pyc"  -delete

데이터베이스를 제거한다. 기본 SQLite 엔진으로 개발 중이라면 db.sqlite3 파일을 삭제한다.

초기 마이그레이션 파일을 생성하고 데이터베이스 스키마를 생성한다.

python manage.py makemigrations
python manage.py migrate

두 번째 시나리오

마이그레이션 파일은 모두 지우지만 데이터베이스 데이터는 유지하고 싶은 경우이다.

현재 반영 안 된 마이그레이션이 없는지 확인한다.

python manage.py makemigrations

위와 같이 명령하여 아래 메시지를 확인하면 추가로 반영할 마이그레이션이 없는 경우다.

No changes detected

그러나 추가로 마이그레이션 파일이 만들어지면 이를 아래와 같이 명령하여 반영하도록 한다.

python manage.py migrate

프로젝트 앱 마이그레이션 히스토리 삭제

python manage.py showmigrations

위와 같이 명령하면 프로젝트 안에 앱들의 마이그레이션 히스토리를 볼 수 있다.

admin
 [X] 0001_initial
 [X] 0002_logentry_remove_auto_add
auth
 [X] 0001_initial
 [X] 0002_alter_permission_name_max_length
 [X] 0003_alter_user_email_max_length
 [X] 0004_alter_user_username_opts
 [X] 0005_alter_user_last_login_null
 [X] 0006_require_contenttypes_0002
 [X] 0007_alter_validators_add_error_messages
 [X] 0008_alter_user_username_max_length
blog
 [X] 0001_initial
 [X] 0002_auto_20170610_1904
 [X] 0003_auto_20170610_1906
 [X] 0004_auto_20170610_2044
 [X] 0005_auto_20170613_1152
 [X] 0006_post_description
contenttypes
 [X] 0001_initial
 [X] 0002_remove_content_type_name
sessions
 [X] 0001_initial

위 예제에서는 blog 앱의 마이그레이션 파일을아래와 같이 명령하여 초기화한다.

python manage.py migrate --fake blog zero

위 명령어의 결과는 아래와 같다.

Operations to perform:
  Unapply all migrations: blog
Running migrations:
  Rendering model states... DONE
  Unapplying blog.0006_post_description... FAKED
  Unapplying blog.0005_auto_20170613_1152... FAKED
  Unapplying blog.0004_auto_20170610_2044... FAKED
  Unapplying blog.0003_auto_20170610_1906... FAKED
  Unapplying blog.0002_auto_20170610_1904... FAKED
  Unapplying blog.0001_initial... FAKED

다시 아래와 같이 마이그레이션 히스토리를 확인하기 위해 명령할 수 있다.

python manage.py showmigrations

아래 결과에서 blog의 경우에는 마이그레이션 히스토리 앞에 [X] 표시가 사라진 것을 확인할 수 있다.

admin
 [X] 0001_initial
 [X] 0002_logentry_remove_auto_add
auth
 [X] 0001_initial
 [X] 0002_alter_permission_name_max_length
 [X] 0003_alter_user_email_max_length
 [X] 0004_alter_user_username_opts
 [X] 0005_alter_user_last_login_null
 [X] 0006_require_contenttypes_0002
 [X] 0007_alter_validators_add_error_messages
 [X] 0008_alter_user_username_max_length
blog
 [ ] 0001_initial
 [ ] 0002_auto_20170610_1904
 [ ] 0003_auto_20170610_1906
 [ ] 0004_auto_20170610_2044
 [ ] 0005_auto_20170613_1152
 [ ] 0006_post_description
contenttypes
 [X] 0001_initial
 [X] 0002_remove_content_type_name
sessions
 [X] 0001_initial

마이그레이션 파일 삭제

blog 앱의 마이그레이션 디렉토리 안에 __init__.py 파일을 빼고 모두 삭제한다. 그리고 다시 아래와 같이 마이그레이션 히스토리를 확인해본다.

python manage.py showmigrations

그러면 아래와 같이 blog 앱에는 마이그레이션이 없다는 결과를 확인할 수 있다.

admin
 [X] 0001_initial
 [X] 0002_logentry_remove_auto_add
auth
 [X] 0001_initial
 [X] 0002_alter_permission_name_max_length
 [X] 0003_alter_user_email_max_length
 [X] 0004_alter_user_username_opts
 [X] 0005_alter_user_last_login_null
 [X] 0006_require_contenttypes_0002
 [X] 0007_alter_validators_add_error_messages
 [X] 0008_alter_user_username_max_length
blog
 (no migrations)
contenttypes
 [X] 0001_initial
 [X] 0002_remove_content_type_name
sessions
 [X] 0001_initial

초기 마이그레이션 파일 생성

이제 초기 마이그레이션 파일을 만들기 위해 아래와 같이 명령한다.

python manage.py makemigrations

최초 마이그레이션 파일 0001_initial.py이 생성된 것을 확인할 수 있다.

Migrations for 'blog':
  blog\migrations\0001_initial.py
    - Create model Post

페이크 마이그레이션

데이터베이스 테이블이 이미 존재하기 때문에 초기 마이그레이션 파일을 적용할 수 없다. 따라서 마치 마이그레이션을 한 것처럼 아래와 같이 명령하여 페이크 마이그레이션한다.

python manage.py migrate --fake-initial

결과는 다음과 같다.

Operations to perform:
  Apply all migrations: admin, auth, blog, contenttypes, sessions
Running migrations:
  Applying blog.0001_initial... FAKED

그리고 최종 마이그레이션 히스토리를 보면 아래와 같이 blog 앱에는 0001_initial 마이그레이션만 반영된 것으로 확인할 수 있다.

python manage.py showmigrations
admin
 [X] 0001_initial
 [X] 0002_logentry_remove_auto_add
auth
 [X] 0001_initial
 [X] 0002_alter_permission_name_max_length
 [X] 0003_alter_user_email_max_length
 [X] 0004_alter_user_username_opts
 [X] 0005_alter_user_last_login_null
 [X] 0006_require_contenttypes_0002
 [X] 0007_alter_validators_add_error_messages
 [X] 0008_alter_user_username_max_length
blog
 [X] 0001_initial
contenttypes
 [X] 0001_initial
 [X] 0002_remove_content_type_name
sessions
 [X] 0001_initial

요약하면 아래와 같은 순서로 명령한다.

  1. python manage.py makemigrations
  2. python manage.py showmigrations
  3. python manage.py migrate --fake 프로젝트_앱 zero
  4. 마이그레이션 파일 삭제
  5. python manage.py makemigrations
  6. python manage.py migrate --fake-initial




출처 : https://wikidocs.net/9926


And

Intent FALG

|

FLAG_ACTIVITY_ 라는 접두어를 사용하여


_CLEAR_TOP

자신까지 포함하여 제거 후 onCreate() 다시 호출하여 재활용함


_SINGLE_TOP

재사용

onPasue() / onNewIntent() / onResume() 순차적으로 호출함


_NO_HISTORY

스택에 추가되지 않음

ex) 팝업, 이벤트성


_REORDER_TO_FRONT

task에 이미 존재하는 Activity라면 스택 최상단으로 옮기는 플래그

주의) task의 순서를 뒤섞는 점에서 사용주의


관련자료

http://developer.android.com/reference/android/content/Intent.html

http://chihun80.springnote.com/pages/6423199

And
prev | 1 | 2 | 3 | 4 | next