> А нужна — банальная постоянная вентиляция. Летом прокатит _постоянно_ открытая форточка или балкон, зимой — либо продолжать держать открытым форточку
Вот поэтому я и не работаю в офисе =)
Кстати, мне врач подобную проблему диагностировала, поглядев на энцефалограмму =) Но может быть просто потому, что у меня не усталость основная проблема. Я-то знала, чем для меня закрытая форточка заканчивается =)
Такое поведение не с тестами связано, а с внутренними правилами HR-отдела компании, которая проводит собеседование. У меня бывало по-всякому, но после тестовых заданий всегда на работу брали =))) Если бы не выполнила, не знаю, как в таких случаях реагировать принято.
> На текущем этапе мы работали над приложением для стандартного Android-планшета, которое призвано упростить пожилым людям использование цифровой информации, поэтому для определённости в дальнейшем будем называть наше решение «Планшетом для пожилых» (ПП).
Я могу рассказать почему не купила маме планшет. Да и в комментах к предыдущему посту о такой проблеме рассказывали. Если у планшета возникает какая-то проблема, необходимо личное присутствие более-менее грамотного человека, желательно с компьютером. Например, после того как альтернативно одарённый интернет-провайдер вдруг изменил способ доступа в интернет, при помощи netbook-а и телефона я сомгла помочь маме настроить роутер. Как сделаить тоже самое планшетом я не представляю.
Хотя пока вы приложение доведёте до финальной версии, упомянутая мной проблема может сама собой рассосаться.
Да, есть такая проблема. Мы покупали компьютеры троим родителям. И что интересно: папа мужа, который может собрать и разобрать жигули и моя мама, проектировавшая спутники связи, воспринимали, особенно поначалу, современные интерфейсы гораздо хуже свекрови, которая всю жизнь техникой особо не интересовалась и не занималась.
А точный момент этих изменений, стало быть, не важен? Удобнее раз в, скажем, час ходить и проверять время изменения таблицы, чем повесить тот же trigger?
Вы тоже сходите проголосуйте за баг, плиз. И/или за второй, который я по мотивам этого топика открыла: bugs.mysql.com/bug.php?id=69673
Это разумно, но опять-таки, я боюсь, что если сделать эту фичу для InnoDB мы упрёмся в поддержку ACID и, в связи с этим, в производительность. Хотя в памяти, наверное, можно сделать. Или в performance schema.
В принципе имеет смысл написать как это может использоваться и нажать кнопку «Affects Me».
PS: Баг этот, кстати, типичный пример внтуренней конвертации бага в feature request.
Понятно, спасибо! С одной стороны, логично зачем эта фича нужна и тут, в самом деле, хоть дату модификации файлов смотри. Но у меня есть 2 вопроса.
Вопрос 1. В исходном комментарии человек упомянул таблицу с 10 миллионами записей. Я так полагаю, что все они в кэше? Так как демон из п. 4 проверяет, изменились ли какие-то данные, то какие именно изменились его не интересует. То есть при изменении одной строки обновляется кэш целиком? Все 10 миллионов записей?
Я правильно понимаю, что работает это примерно так.
1. При старте MySQL создаётся независимый от него кэш
2. Какое-то приложение читает данные из кэша и в MySQL вообще не ходит
3. Другое приложение пишет в MySQL, но о кэше из п. 1 ничего не знает
4. Демон раз в N секунд проверяет, изменились ли данные и если да, то обновляет кэш для одной таблицы.
Вы можете мне ответить зачем нужен «ластапдейт неважно каких данных»? Я, правда, не вижу business case для этого. Что Вы будете с ним делать? Объясните, пожалуйста.
Не поняла зачем триггер вешать? Одно поле, автоматически обновляющееся, не должно затронуть правильно спроектированное приложение вообще. То есть, таблица
CREATE TABLE t1(
id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
f1 INT,
f2 VARCHAR(255)
....
, переписанная во что-то вроде:
CREATE TABLE t1(
id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
last_updated TIMESTAMP NOT NULL,
f1 INT,
f2 VARCHAR(255)
....
позволит, не меняя правильно написанные запросы, получить точно сам факт свершившегося апдейта. Одним запросом.
Но Вы мне так и не ответили зачем Вам это нужно для всех таблиц.
Вы не подскажете ещё зачем это нужно для всех таблиц? Я могу придумать только две причины:
1. Отладка.
2. Инкрементный бэкап. Но для бэкапа хранится LSN и его прекрасно используют MySQL Enterprise Backup и Percona XtraBackup
А вот в плане бизнес-логики обычного приложения мне кажется, что поле TIMESTAMP гораздо удобнее. Потому что, если поменялась таблица, скажем, с ценами, мне будет интересно узнать какая именно цена изменилась, а не сам факт того, что что-то поменялось.
Да причём здесь это вообще! Вы правда считаете, что инженеры MySQL не могут две минуты подумать как баг пофиксить лучшим образом? Мой личный комментарий хотя бы прочитайте:
[28 Jun 19:54] Sveta Smirnova
…
Although now, in year 2013, I don't like that this will break backward compatibility for --no-data option: I assume some of users like current behavior. Probably official patch should have separate option for resetting current AUTO_INCREMENT value.
Он был сделан до того, как я этот топик увидела.
И такое происходит с каждым первым багом. Пользователи не обязаны думать за разработчиков какое решение лучше или какое нет.
Нет, конечно, если формулировка совсем плохая, инженер может просто не понять что хочет пользователь. И такие случаи бывали. Как правило мы всё равно отвечаем почему bug rejected и большинство пользователей объясняют уже подробно. После чего решение о закрытии бага пересматривается.
Я в доме всех построила.Ну реально, дома проще договориться.Вот поэтому я и не работаю в офисе =)
Кстати, мне врач подобную проблему диагностировала, поглядев на энцефалограмму =) Но может быть просто потому, что у меня не усталость основная проблема. Я-то знала, чем для меня закрытая форточка заканчивается =)
Я могу рассказать почему не купила маме планшет. Да и в комментах к предыдущему посту о такой проблеме рассказывали. Если у планшета возникает какая-то проблема, необходимо личное присутствие более-менее грамотного человека, желательно с компьютером. Например, после того как
альтернативно одарённыйинтернет-провайдер вдруг изменил способ доступа в интернет, при помощи netbook-а и телефона я сомгла помочь маме настроить роутер. Как сделаить тоже самое планшетом я не представляю.Хотя пока вы приложение доведёте до финальной версии, упомянутая мной проблема может сама собой рассосаться.
А точный момент этих изменений, стало быть, не важен? Удобнее раз в, скажем, час ходить и проверять время изменения таблицы, чем повесить тот же trigger?
Вы тоже сходите проголосуйте за баг, плиз. И/или за второй, который я по мотивам этого топика открыла: bugs.mysql.com/bug.php?id=69673
В принципе имеет смысл написать как это может использоваться и нажать кнопку «Affects Me».
PS: Баг этот, кстати, типичный пример внтуренней конвертации бага в feature request.
Вопрос 1. В исходном комментарии человек упомянул таблицу с 10 миллионами записей. Я так полагаю, что все они в кэше? Так как демон из п. 4 проверяет, изменились ли какие-то данные, то какие именно изменились его не интересует. То есть при изменении одной строки обновляется кэш целиком? Все 10 миллионов записей?
Вопрос 2. В версии 5.6 вот такая фича появилась: dev.mysql.com/doc/refman/5.6/en/innodb-memcached-benefits.html Она не поможет в этом случае?
1. При старте MySQL создаётся независимый от него кэш
2. Какое-то приложение читает данные из кэша и в MySQL вообще не ходит
3. Другое приложение пишет в MySQL, но о кэше из п. 1 ничего не знает
4. Демон раз в N секунд проверяет, изменились ли данные и если да, то обновляет кэш для одной таблицы.
?
> зачем его вообще бездумно везде лепят?
Хорошо, поторопилась. В данном случае, конечно, он не обязателен.
Но вот я правда не понимаю зачем нужен нативный last_update. Тем более, что он есть и называется LSN.
, переписанная во что-то вроде:
позволит, не меняя правильно написанные запросы, получить точно сам факт свершившегося апдейта. Одним запросом.
Но Вы мне так и не ответили зачем Вам это нужно для всех таблиц.
1. Отладка.
2. Инкрементный бэкап. Но для бэкапа хранится LSN и его прекрасно используют MySQL Enterprise Backup и Percona XtraBackup
А вот в плане бизнес-логики обычного приложения мне кажется, что поле TIMESTAMP гораздо удобнее. Потому что, если поменялась таблица, скажем, с ценами, мне будет интересно узнать какая именно цена изменилась, а не сам факт того, что что-то поменялось.
Он был сделан до того, как я этот топик увидела.
И такое происходит с каждым первым багом. Пользователи не обязаны думать за разработчиков какое решение лучше или какое нет.
Нет, конечно, если формулировка совсем плохая, инженер может просто не понять что хочет пользователь. И такие случаи бывали. Как правило мы всё равно отвечаем почему bug rejected и большинство пользователей объясняют уже подробно. После чего решение о закрытии бага пересматривается.