И?

Мы какую сейчас задачу решаем? Вставить запись только если её нет или что ?

это не верно. я наверно сильно затуманил всем голову - но думаю может из этой ситуации лучше через транзакцию выкрутится ?

да, все верно, вставить запись если ее нет, но при этом предваритьельно проверить базу на существование такой же записи но под другим id - который уникальный и праймари

это не верно. я наверно сильно затуманил всем голову - но думаю может из этой ситуации лучше через транзакцию выкрутится ?

Нет, ни при чём тут транзакции.

да, все верно, вставить запись если ее нет, но при этом предваритьельно проверить базу на существование такой же записи но под другим id - который уникальный и праймари

Сделай ещё альтернативный уникальный ключ, помимо PK, по которому ты будешь проверять, что "такая запись уже есть".

о - вот это гуд идея - спасибо я про это не подумал!

Как бы предыдущий мой совет без этого всё равно не работал бы...

Как бы предыдущий мой совет без этого всё равно не работал бы...

Спс все получилось - даже 2-й кюч не пришлось задействовать - только 1 - вот сам кверик : insert into areas (com_port, phone, area, acct, acct_counter, data_incoming, time_incoming) SELECT 'COM4', '+99999999999', '12', '143848', '1050', '2017-07-26', '07:50:45' FROM areas WHERE NOT EXISTS (SELECT * FROM areas WHERE com_port = 'COM4' AND phone = '+99999999999' AND area = '12' AND acct = '143848' AND acct_counter = '1050' AND data_incoming = '2017-07-26' AND time_incoming = '07:50:45' AND id != 0 ) LIMIT 1;

Есть проект DB, который хранит всю инфу только о базе (changeSet'ы и тд), а есть другие enterprise проекты, для работоспособности которых необходимы данные таблицы из проекта DB. Если проект N1 накатил свои изменения в DB, а потом выяснилось, что они не нужны, ему придется их откатывать. Примерно такая схема.

up

храните просто чейнджсеты в разных таблицах и не допускайте того, чтобы два проекта пытались заменеджить один и тот же объект

если вы, грубо говоря, в проекте 2 видите, что в проекте DB вам не хватает полей, то это на самом деле значит, что проект DB должен их объявить, а проект 2 - дождаться

дело не в конфликте мержей.

я скорее сумбурно объяснил

конфликта нет, все работает, но нужно откатить состояние (liquibase, не vcs)

можно ли как-то централизовано откатить до какого-то состояния

?

обычный роллбэк

понял, спасибо

Товарищи, такой вопрос по монге. Можно юзеров привязать к реквестам в одной коллекции: { 'login': blah, 'email': bar, 'password': foo, requests: [ { 'payload': foobar, 'document_id': baz } ] } А можно хранить референс на юзера в отдельной коллекции реквестов: { 'login': blah, 'email': bar, 'password': foo } --- { 'user_login': blah, 'payload': foobar, 'document_id': baz } Первый железно удостоверяет, что реквест без юзера существовать не может. Второй выглядит как SQL-way, но чуть поаккуратнее первого. Как будет Mongo-way?

а как он у вас появится без юзера?

и что вы будете делать, когда запросов у одного пользователя наберется больше, чем на предел размера документа?

и что вы будете делать, когда запросов у одного пользователя наберется больше, чем на предел размера документа?

Думаю такого не будет (стандартная отмазка про то, что 16мб это много).

а как он у вас появится без юзера?

В коде реквест появляется как User.from_database(blah).add_request(foo)

Думаю такого не будет (стандартная отмазка про то, что 16мб это много).

я видел фильм ужасов, который начинался с такой фразы

Но если всунуть его внутрь, то и в базе он без юзера не сможет появиться.

Ага, а как он вообще у вас может появиться без юзера при альтернативной обработке?

Ага, а как он вообще у вас может появиться без юзера при альтернативной обработке?

В смысле альтернативной обработке?

В смысле не вытаскивать перед этим пользователя из базы

Точнее даже не так

если мы поменяем функцию persist(id, request) { db.getUser(id).requests.push(request) } на persist(id, request) { request.user = id db.requests.push(request) То каким образом может получиться ситуация, в которой айдишник не принадлежит какому-то юзеру?

сейчас просто моделируется ситуация "прилетит космический луч и нарисует айдишник из воздуха"

Нууу... если кто-то будет юзать код не по докам и создавать реквест через встроенный init питона.

с тем же успехом он может получить прямое поджключение к базе и напихать вам вообще чего угодно

сейчас просто моделируется ситуация "прилетит космический луч и нарисует айдишник из воздуха"

Примерно, лол.

Ее не будет. Null (None) там где не нужно нарисоваться может, но скорее это будет простой недосмотр в коде и защищаться от него надо валидацией перед сохранением, а не разухабливая записи на килобайты.

Ок, спасибо!

всем привет. может подскажите что.. 2 сервера, freebsd 9 и11, mysql 5.5 и 5.6 соответственно, базы одинаковые, конфиг мускула - одинаковый. но один и тот же запрос с like на 5.5 занимает 0002 секунды, а на 5.6- 2-3 секунды

всем привет. может подскажите что.. 2 сервера, freebsd 9 и11, mysql 5.5 и 5.6 соответственно, базы одинаковые, конфиг мускула - одинаковый. но один и тот же запрос с like на 5.5 занимает 0002 секунды, а на 5.6- 2-3 секунды

Ответ может крыться в разности

пример?

сорри, фс и версии ос? в нем?

И даже в железе

хм.. затык то только в LIKE.. и серьезных нагрузок нет..

Но ответ все равно там

Сравниваете же полностью разные системы

спасибо, потестим. может откачусь на 5.5

всем привет. может подскажите что.. 2 сервера, freebsd 9 и11, mysql 5.5 и 5.6 соответственно, базы одинаковые, конфиг мускула - одинаковый. но один и тот же запрос с like на 5.5 занимает 0002 секунды, а на 5.6- 2-3 секунды

Погугли index condition pushdown

Оно как раз в 5.6 появилось

Спасибо, гляну

всем привет. может подскажите что.. 2 сервера, freebsd 9 и11, mysql 5.5 и 5.6 соответственно, базы одинаковые, конфиг мускула - одинаковый. но один и тот же запрос с like на 5.5 занимает 0002 секунды, а на 5.6- 2-3 секунды

Дмитрий, посмотри планы запросов хотя бы. Потом, то, что у запросов разные времена выполнения, не говорит ни о чём. Секундой больше, секундой меньше — не показатель

2 идентичные базы по всему - объем данных, типы таблиц.. Основное отличие- ос, фс и версия mysql. И разница не в секунду, а на несколько порядков. 0.002 против 2.

ERROR: S client not available

Если такой же запрос, но без like-все отлично, но like необходим

Смотри планы на обоих машинах.

Сравнивай DDL таблиц

Но даже при этом у тебя разные могут планы и запросы по-разному работать — версии MySQL у тебя разные.

эксплейн-то сравните/покажите

Не покажет, он же гордый!

больше всего на свете на свою реплику я хотел получить заправскую шутейку

Не могу сейчас показать, в пн, не раньше..

Короче кругом виновен, извиняюсь, что, задав вопрос, не смог показать полную картину. Не стебусь -

Сам все понимаю

Дмитрий, на самом деле нам там смотреть особо и не на что, это для тебя. Посмотри планы запросов там и там, посмотри, чем план на "плохом" отличается от "хорошего", попытайся понять, почему. Если поймёшь сам, там индекса нет или что — хорошо. Если планы одинаковые — значит, что-то совсем не так в "плохом" с конфигурацией, либо просто случайный эффект (например, кэш данных не был заполнен) Если планы разные и непонятно почему — вот тогда можешь показывать и плакаться.

мне всегда нравилась политика mysql с новыми фичами

они все включают по-умолчанию

План это explain?

да

С ходу не вспомню, сравню,

если не разберешься: присылай планы, ddl таблицы и вывод SELECT @@optimizer_switch;

DDL всех таблиц на двух серверах!

И лучше не присылать, а на pastebin...

Да на gist положу, не проблема

Кто все эти люди? ?

Это не люди, это либо хры, либо боты. Не знаю, что хуже.