PHP.SU

Программирование на PHP, MySQL и другие веб-технологии
PHP.SU Портал     На главную страницу форума Главная     Помощь Помощь     Поиск Поиск     Поиск Яндекс Поиск Яндекс     Вакансии  Пользователи Пользователи


 Страниц (1): [1]   

> Описание: Или история эпичного промаха
EuGen Администратор
Отправлено: 29 Апреля, 2011 - 10:38:23
Post Id


Профессионал


Покинул форум
Сообщений всего: 9097
Дата рег-ции: Июнь 2007  
Откуда: Berlin


Помог: 707 раз(а)




Итак, редко создаю здесь темы, но ситуцаия настолько курьезна, что не мог не поделиться.
Предыстория - есть некий процесс, обрабатывающий файлы, и по окончанию обработки кладущий их имена в таблицу (помечая что они обработаны). Таким образом, чтобы вручную обработать файл вновь, требуется удалить из таблицы соответствующую строку.
Делал это я многократно, без каких-либо происшествий.
Но долго ли коротко ли, потребовалось сделать повторную обработку снова. Выполняю выборку и смотрю, что у требемого для удаления файл id=66. Конечно, не придал этому значения.
Как всегда проверил дату создания записи и решил ее как обычно удалить.
Но что-то опечатался я вроде незначительно, а именно:
CODE (SQL):
скопировать код в буфер обмена
  1.  
  2. DELETE FROM cb_mt_exchange_files WHERE id-66;
  3.  

Отправил серверу... неприятно было увидеть это:
CODE (htmlphp):
скопировать код в буфер обмена
  1.  
  2. Query OK, 18 rows affected (0.09 sec)  
  3.  

И финал.. увидев такой результат и вчитавшись в запрос выше, делаю:
CODE (htmlphp):
скопировать код в буфер обмена
  1.  
  2. mysql> select * from cb_mt_exchange_files;
  3. +----+-------------------------+---------------------+----------+------------+----------+-----------+------+
  4. | id | name                    | createDate          | authorId | activeFlag | siteCode | direction | type |
  5. +----+-------------------------+---------------------+----------+------------+----------+-----------+------+
  6. | 66 | xx-2011042700000002.res | 2011-04-29 08:40:18 |        0 |          1 |          |           |      |
  7. +----+-------------------------+---------------------+----------+------------+----------+-----------+------+
  8.  

Много думал...
P.S. восстановился из бекапа через 2 минуты..


-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.
 
 Top
Uchkuma
Отправлено: 29 Апреля, 2011 - 11:00:15
Post Id



Участник


Покинул форум
Сообщений всего: 1539
Дата рег-ции: Март 2010  
Откуда: Киров


Помог: 6 раз(а)




То же что и !=? Сокращенная запись? Недокументированная возможность? Однако
 
 Top
EuGen Администратор
Отправлено: 29 Апреля, 2011 - 11:02:13
Post Id


Профессионал


Покинул форум
Сообщений всего: 9097
Дата рег-ции: Июнь 2007  
Откуда: Berlin


Помог: 707 раз(а)




Нет... id-66 просто вычислилось как выражение и привелось затем к булевому типу.
Ведь, скажем, WHERE 1 - допустимая конструкция.
То есть оно было не 0 разумеется только для id отличных 66 (ибо только 66-66=0, остальное будет больше или меньше 0, то есть приведется к TRUE)


-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.
 
 Top
Uchkuma
Отправлено: 29 Апреля, 2011 - 11:05:34
Post Id



Участник


Покинул форум
Сообщений всего: 1539
Дата рег-ции: Март 2010  
Откуда: Киров


Помог: 6 раз(а)




Да, но почему тогда id=66 осталась?

Ясно.
(Добавление)
Кстати, оригинальный способ заменить оператор != или <> Улыбка
 
 Top
EuGen Администратор
Отправлено: 29 Апреля, 2011 - 11:10:03
Post Id


Профессионал


Покинул форум
Сообщений всего: 9097
Дата рег-ции: Июнь 2007  
Откуда: Berlin


Помог: 707 раз(а)




Да. Такая вот арифметика. Полезного отсюда извлечь можно -
0. Сделать SELECT до того, как делать DELETE
1. Сделать проверку на тестовой БД
2. Делать бекап данных
3. Добавлять LIMIT
Хотя... я сделал все, кроме последнего и все равно от опечатки это не страхует. LIMIT же в моем случае удалил бы первую попавшуюся ценную запись, искать бы ее еще потом..

Заменить != получится только для типов данных, к которым применимо такое действие.


-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.
 
 Top
Champion Супермодератор
Отправлено: 29 Апреля, 2011 - 15:49:54
Post Id



Активный участник


Покинул форум
Сообщений всего: 4350
Дата рег-ции: Авг. 2008  
Откуда: Москва


Помог: 57 раз(а)




Вот, кстати, например, с firebird я когда работал через ibExpert, там была возможность после каждого запроса явно выполнить commit / rollback. И это было очень замечательно, как раз в таких ситуациях, потому что не успев испугаться можно было откатить транзакцию. В mysql-ных ГУИшках я такого не встречал, хотя транзакции mysql поддерживает.
Может быть всё-таки есть такая возможность в мускульных ГУИ?

PS у меня недавно тоже фейл получился. Я, сидя в PMA под рутом, на тестовом серваке случайно тестовую БД дропнул. Не спрашивайте как)
 
 Top
EuGen Администратор
Отправлено: 03 Мая, 2011 - 11:49:16
Post Id


Профессионал


Покинул форум
Сообщений всего: 9097
Дата рег-ции: Июнь 2007  
Откуда: Berlin


Помог: 707 раз(а)




BEGIN .. COMMIT лишний раз заставит подумать о переходе на InnoDB.
Жаль, что не везде используетсыя он.


-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.
 
 Top
Страниц (1): [1]
Сейчас эту тему просматривают: 1 (гостей: 1, зарегистрированных: 0)
« Прочее »


Все гости форума могут просматривать этот раздел.
Только зарегистрированные пользователи могут создавать новые темы в этом разделе.
Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.
 



Powered by PHP  Powered By MySQL  Powered by Nginx  Valid CSS  RSS

 
Powered by ExBB FM 1.0 RC1. InvisionExBB