@pydjango
Django

Полезная информация и правила: https://github.com/amureki/django_faq Вакансии и резюме: @django_jobs Пофлудить идём сюда: @django_flood Статистика чата: combot.org/chat/-1001063854692

1741 members

Архив канала @pydjango 18 ноября 2016 г.

01:45:53 ПП
User 2895769
а если я вот здесь https://github.com/django/django/blob/master/django/db/models/fields/related.py#L943 поменяю _id на _uuid (ну, отнаследуюсь и сделаю свой CustomForeignKey), это мне как-нибудь может аукнуться нехорошо?..
github.com/django/django/blob/master/django/db/models/fields/related.py
django - The Web framework for perfectionists with deadlines.
01:48:18 ПП
User 2895769
просто для порядка) PK у меня uuid
02:54:52 ПП
User 162317186
подскажите пожалуйста как вставить данные в sqllite, желательно через pycharm ?
03:00:43 ПП
User 128333406
User 162317186
подскажите пожалуйста как вставить данные в sqllite, желательно через pycharm ?
настрой коннект к БДчерез PyCharm и работай с таблицами
03:02:27 ПП
User 162317186
вроде настроен
03:02:31 ПП
User 162317186
а как туда импортнуть
03:02:35 ПП
User 162317186
данные
03:02:39 ПП
User 162317186
в готовую таблицу
03:03:28 ПП
User 128333406
импортнуть откуда?
03:08:33 ПП
User 162317186
из .csv файла
03:09:40 ПП
User 128333406
ну, документацию почитать может нужно?
03:09:42 ПП
User 128333406
https://www.sqlite.org/cli.html
03:09:57 ПП
User 128333406
там же есть секция CSV Import
03:19:33 ПП
User 162317186
спасибо
03:19:46 ПП
User 162317186
я думал есть какой-то функционал гуйный
03:20:03 ПП
User 128333406
да зачем он нужен, там 1 строчка в консольке
03:20:30 ПП
User 128333406
но может и есть GUI для SQLLite
03:20:58 ПП
User 162317186
попробую
03:21:36 ПП
User 18500084
User 2895769
а если я вот здесь https://github.com/django/django/blob/master/django/db/models/fields/related.py#L943 поменяю _id на _uuid (ну, отнаследуюсь и сделаю свой CustomForeignKey), это мне как-нибудь может аукнуться нехорошо?..
github.com/django/django/blob/master/django/db/models/fields/related.py
django - The Web framework for perfectionists with deadlines.
https://docs.djangoproject.com/en/1.8/ref/models/fields/#django.db.models.ForeignKey.to_field
03:21:44 ПП
User 18500084
это не для вашего случая?
03:22:47 ПП
User 18500084
FK же так и так к primary key цепляется, если я не ошибаюсь, если у вас uuid в качестве pk, все должно сработать автоматически
03:24:12 ПП
User 2895769
User 18500084
это не для вашего случая?
мне хочется массово это сделать для всех FK
03:24:39 ПП
User 18500084
у вас во всех моделях есть uuid?
03:24:48 ПП
03:24:58 ПП
User 2895769
там, где мои модели
03:25:14 ПП
User 2895769
я по умолчанию делаю uuid1
03:25:46 ПП
User 2895769
и мне немного не нравится, что он по умолчанию старается их называть что-то_там_id
03:25:59 ПП
User 2895769
хотя там везде uuid = ...
03:26:16 ПП
User 2895769
называл бы хотя бы _fk тогда уж
03:27:52 ПП
User 18500084
User 2895769
там, где мои модели
и они все primary_key?
03:28:04 ПП
User 2895769
ну да
03:28:30 ПП
User 18500084
тогда оно к нему и должно цеплять, как я писал выше
03:29:54 ПП
User 2895769
db_column правильный случай, просто не массовый)
03:31:08 ПП
User 2895769
просто какое бы поле там ни было, он всё равно _id добавит в FK, что как-то криво)
03:32:40 ПП
User 18500084
никто не идеален
это как-то мешает работе?)
03:32:46 ПП
User 2895769
User 18500084
никто не идеален
это как-то мешает работе?)
нет
03:33:08 ПП
User 2895769
User 18500084
никто не идеален
это как-то мешает работе?)
мне просто не нравится, что у FK в названии _id, а тип поля UUID
03:33:22 ПП
User 18500084
UUID это все равно id :D
03:33:33 ПП
User 2895769
было бы вместо _id, например, _fk, я бы не возмущался
03:33:56 ПП
User 18500084
не знаю, логично вроде
03:34:05 ПП
User 18500084
он на идентификатор ссылается
03:34:08 ПП
User 2895769
просто когда PK называется id, то логично
03:34:17 ПП
User 2895769
а когда PK называется uuid
03:34:27 ПП
User 2895769
то логичнее или _uuid или _fk но не _id
03:35:17 ПП
User 18500084
UUID не ID?
03:35:37 ПП
User 2895769
ну , там могло быть code = ...
03:35:52 ПП
User 18500084
все везде могло быть
03:35:56 ПП
User 2895769
логичнее всего _fk
03:36:00 ПП
User 2895769
вместо _id
03:36:10 ПП
User 18500084
ладно, ладно, раз вы такой упертый, перепишите внутрянку, может ничего и не поломается

в а идеале, запилите патч и PR в джангу
03:36:15 ПП
User 18500084
так будет правильнее
03:58:43 ПП
User 107485588
uuid в качестве праймери кей? о_О
03:58:54 ПП
User 107485588
а зачем если не секрет?
04:11:56 ПП
User 18500084
Для предотвращения коллизий, наверное
04:19:58 ПП
User 2895769
User 107485588
а зачем если не секрет?
ну, вдруг мне потом придётся разделять таблицу и держать на разных серверах)
04:20:47 ПП
User 2895769
uuid4 может повторяться (оооочень маловероятно правда), а вот uuid1 не должен
04:21:46 ПП
User 2895769
но чем больше нод - тем выше риск, что повторяться оно будет (uuid4)
04:21:49 ПП
User 107485588
А как же перфоманс? При джоинах например
04:22:03 ПП
User 2895769
c uuid медленнее, конечно)
04:22:31 ПП
User 2895769
но если всё в кешах, то особо разницы и нет
04:23:00 ПП
User 107485588
А почему не держать колонку с юидом просто рядом, в отдельной колонке
04:23:13 ПП
User 107485588
Ну все в кеш не запихнешь)
04:24:08 ПП
User 2895769
мне нравится и другая особенность uuid - можно скрывать количество объектов в таблице и темпы роста этого количества
04:24:51 ПП
User 2895769
то есть если светить обычные id'шники - будет понятно, сколько у вас в системе, к примеру, юзеров или проектов или чего-нибудь там ещё
04:25:03 ПП
User 2895769
и можно измерить, сколько добавилось за месяц
04:50:15 ПП
User 18500084
User 2895769
то есть если светить обычные id'шники - будет понятно, сколько у вас в системе, к примеру, юзеров или проектов или чего-нибудь там ещё
А можно использовать норм ид для внутренних нужд, а наружу показывать ууид или любой другой рандом
04:51:49 ПП
User 82569033
User 18500084
А можно использовать норм ид для внутренних нужд, а наружу показывать ууид или любой другой рандом
Просто добавляем генератор некий и колонку в таблицу?
04:52:35 ПП
User 2895769
если нам потребуется потом разделить таблицы, то с числовыми идентификаторами будет сложнее
04:54:34 ПП
User 2895769
uuid1 же повторяться не будут ( https://hg.python.org/cpython/file/3.6/Lib/uuid.py#l529 )
04:55:24 ПП
User 2895769
а кешировать всё равно придётся, с любыми идшниками
04:58:29 ПП
User 2895769
допустим, у нас есть некие операции, которые выполняются каждый день и по итогам этого куда-нибудь пишется лог, а в базу нужно записать состояние операции и ссылку на этот лог
04:59:04 ПП
User 2895769
допустим, у нас 100 тысяч клиентов и по каждому 1 раз в день добавляется запись в таблицу
04:59:45 ПП
User 2895769
ограничения на таблицу 32Тб, как бы много, но рано или поздно это израсходуется
05:00:14 ПП
User 2895769
значит, мы будем писать, допустим, каждый год в свою таблицу
05:01:45 ПП
User 2895769
и будет меньше ошибок, если идшники повторяться не будут)
05:10:17 ПП
User 100243492
User 2895769
и будет меньше ошибок, если идшники повторяться не будут)
для этого имеется партицирование
05:13:13 ПП
User 82569033
гайс, через {% url %} можно 2 аргумента передать?
05:13:33 ПП
User 378433
Да хоть десять
05:13:39 ПП
User 378433
Хоть аллаха передавай
05:13:49 ПП
User 378433
Лишь бы сматчилось с какой-то урлой
05:16:49 ПП
User 2895769
User 100243492
для этого имеется партицирование
оно вроде только недавно научилось работатьс разными серверами
05:18:42 ПП
User 2895769
ничего не имею против партиционирования в PostgreSQL 9.5 и выше, впрочем
05:19:46 ПП
User 2895769
но вот с UUID это всё можно реализовать вполне стандартным способом, это удобно
05:25:03 ПП
User 2895769
uuid1 ещё чем интересен - из него можно восстановить дату создания и понять, к какой таблице или серверу делать запрос
05:25:20 ПП
User 2895769
как-нибудь так http://stackoverflow.com/questions/3795554/extract-the-time-from-a-uuid-v1-in-python
stackoverflow.com/questions/3795554/extract-the-time-from-a-uuid-v1-in-python
I have some UUIDs that are being generated in my program at random, but I want to be able to extract the timestamp of the generated UUID for testing purposes. I noticed that using the fields access...
05:36:01 ПП
User 100243492
User 2895769
ничего не имею против партиционирования в PostgreSQL 9.5 и выше, впрочем
У постгреса намного раньше имеется эта поддержка
06:34:29 ПП
User 2895769
я особо не вчитывался, но видел что-то такое https://www.depesz.com/2015/04/02/waiting-for-9-5-allow-foreign-tables-to-participate-in-inheritance/
06:35:18 ПП
User 2895769
вот это решение с UUID1 мне нравится
06:35:50 ПП
User 2895769
у нас 1 ключ, который уникальный и по которому без дополнительных запросов куда-либо можно узнать, куда делать запрос для получения данных по этому ключу