ERROR 1292 (Truncated incorrect INTEGER value: 'd3ea87d0c34cce2260b260b968897787 ?

pilot911

Новичок
Автор оригинала: vovanium
pilot911

А откуда ты знаешь что работает? mysql_insert_id возвращает md5? :)

я не использовал mysql_insert_id для получения строковых ключей ;)

проверил в 5.0.67


[SQL]


INSERT INTO be_session
(
id,
ses_userid,
ses_name,
ses_tstamp,
ses_iplock
) VALUES (
'177e722b72cfade62619793d43aaeecc',
0,
'be_user_session',
1238613229,
'127.0.0.1'
) ON DUPLICATE KEY UPDATE id=LAST_INSERT_ID(id),
id='177e722b72cfade62619793d43aaeecc',
ses_userid=0,
ses_name='be_user_session',
ses_tstamp=1238613229,
ses_iplock='127.0.0.1';

select LAST_INSERT_ID();
[/SQL]



запрос в консоле вернул 177 ;)


так что - как ни странно, работает даже со строковыми ключами, хотя записей в таблице всего 3
 

pilot911

Новичок
Автор оригинала: vovanium
Интересно почему? :)

Оно работает точно также и в 5.1, в твоем случае в 5.1 наверное в STRICTе работает...
не знаю... так получилось, что строковые ключи только от ID сессий строятся.. в других местах они не нужны, в принципе

хотя.. сейчас подумал.. таким образом нарушаю принцип системы, когда любая таблица должна иметь целочисленное поле ID


ПС... это и есть решение проблемы
 

vovanium

Новичок
так что - как ни странно, работает даже со строковыми ключами, хотя записей в таблице всего 3
Да уж, и ты еще свою cms пишешь, предстаставляю какой там ужас внутри :)

Тебя даже не смущает, что в 5.0.67 тебе не вернуло '177e722b72cfade62619793d43aaeecc'?

Могу тебя порадовать в 5.1.30 тоже возвращает 177, потому что твоя md5-строка преобразовывается в число ;)
 

svetasmirnova

маленький монстрик
pilot911
> странно, на 5.0.67 этот запрос отрабатывается...
Неправда, как был warning, так и есть
SQL_MODE у тебя что?

флоппик
> как часто бывает, интересный вопрос останется неотвеченным

Какой ворос? "Т.е. автоинкремент для этого как таковой - не нужен. Другой вопрос - что в нутрях."?

Так вы на него сами ответили выше. И чисто ради занудства - ссылка из мануала: "If expr is given as an argument to LAST_INSERT_ID(), the value of the argument is returned by the function and is remembered as the next value to be returned by LAST_INSERT_ID(). This can be used to simulate sequences" (http://dev.mysql.com/doc/refman/5.1/en/information-functions.html#function_last-insert-id)

В нутрях тип возвращаемого значения longlong:

grep -R Item_func_last_insert_id .
...
./sql/item_func.cc:longlong Item_func_last_insert_id::val_int()

Так что ошибка ожидаемая
 

pilot911

Новичок
Автор оригинала: vovanium
Да уж, и ты еще свою cms пишешь, предстаставляю какой там ужас внутри :)

Тебя даже не смущает, что в 5.0.67 тебе не вернуло '177e722b72cfade62619793d43aaeecc'?

Могу тебя порадовать в 5.1.30 тоже возвращает 177, потому что твоя md5-строка преобразовывается в число ;)
ну почему ужас.. ты пишешь без багов? будь более объективным

-~{}~ 01.04.09 23:36:

Автор оригинала: svetasmirnova
pilot911
> странно, на 5.0.67 этот запрос отрабатывается...
Неправда, как был warning, так и есть

SQL_MODE у тебя что?
STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION



ПС. всем большое спасибо за ответы

ПСС. LAST_INSERT_ID() необходим, поскольку поля в запрос добавляются автоматически - не факт, что среди них будет " id=12, " - актуально, когда происходит INSERT при использовании синтаксиса ON DUPLICATE KEY
 

vovanium

Новичок
ну почему ужас.. ты пишешь без багов? будь более объективным
проблема не в багах, а в логике.
Как можно говорить что в 5.0.67 работает, если вместо ожидаемого '177e722b72cfade62619793d43aaeecc' получаешь 177?

почему LAST_INSERT_ID() не должно быть в этом запросе (допустим, ключ целочисленный)
что-то у тебя мозг вообще не работает, LAST_INSERT_ID() в данном запросе не должно быть, потому что эта функция для целочисленных полей предназначена, а у тебя поле текстовое.
 

svetasmirnova

маленький монстрик
> STRICT_TRANS_TABLES,

Вот и ответ. В 5.0.67 было предупреждение, которого ты не видел. Впрочем это уже тут сказали: http://phpclub.ru/talk/showthread.php?postid=846915#post846915

> LAST_INSERT_ID() необходим,

В приведённом запросе он не нужен
 

vovanium

Новичок
ПСС. LAST_INSERT_ID() необходим, поскольку поля в запрос добавляются автоматически - не факт, что среди них будет " id=12, " - актуально, когда происходит INSERT при использовании синтаксиса ON DUPLICATE KEY
В твоем случае достаточно просто REPLACE вместо INSERT использовать и без всяких ON DUPLICATE KEY (ранова-то это для тебя)
 

pilot911

Новичок
Автор оригинала: vovanium

что-то у тебя мозг вообще не работает, LAST_INSERT_ID() в данном запросе не должно быть, потому что эта функция для целочисленных полей предназначена, а у тебя поле текстовое.
я же написал в примере "допустим, ключ целочисленный" :)

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

-~{}~ 01.04.09 23:53:

Автор оригинала: svetasmirnova
> STRICT_TRANS_TABLES,

Вот и ответ. В 5.0.67 было предупреждение, которого ты не видел. Впрочем это уже тут сказали: http://phpclub.ru/talk/showthread.php?postid=846915#post846915

> LAST_INSERT_ID() необходим,

В приведённом запросе он не нужен
в общем, не нужен, согласен, спасибо за помощь



В твоем случае достаточно просто REPLACE вместо INSERT использовать и без всяких ON DUPLICATE KEY (ранова-то это для тебя)
да нет, к сожалению, REPLACE удалит всю строку, а в ней хранятся сессионные данные пользователя... поэтому только UPDATE
 

vovanium

Новичок
pilot911
я же написал в примере "допустим, ключ целочисленный"
Ты не понимаешь для чего нужна эта функция, поэтому пользоваться тебе ей не нужно, даже если будет ключ целочисленным ;)
 

pilot911

Новичок
Автор оригинала: vovanium
pilot911

Ты не понимаешь для чего нужна эта функция, также как и ON DUPLICATE KEY поэтому пользоваться тебе ими не нужно, даже если будет ключ целочисленным, почитай про REPLACE ;)
ну... пользователь на сайте сделал какие-то настройки, которые сохранились в его сессии... потом только залогинился..

при REPLACE всего его настройки будут удалены ...
 

vovanium

Новичок
pilot911
пардон, это мне показалось что ты все поля обновляешь...
кстати, а зачем для ip поле 40 символов?
Хотя что-то я не пойму зачем тебе тут инсерт? Как твои сессии работают?
По идее получил куку с сессией, делаешь селект по id сессии, если есть то делаешь update для даты, если нет сессии или сессия просрочена делаешь replace создаешь сессию, затирая старую
 

pilot911

Новичок
Автор оригинала: vovanium
pilot911
пардон, это мне показалось что ты все поля обновляешь...
кстати, а зачем для ip поле 40 символов?
для ipv6 на будущее, возможно, переборщил, хватит и 30

-~{}~ 02.04.09 00:11:

Автор оригинала: vovanium
pilot911
пардон, это мне показалось что ты все поля обновляешь...
кстати, а зачем для ip поле 40 символов?
Хотя что-то я не пойму зачем тебе тут инсерт? Как твои сессии работают?
По идее получил куку с сессией, делаешь селект по id сессии, если есть то делаешь update для даты, если нет сессии или сессия просрочена делаешь replace создаешь сессию, затирая старую
так тоже можно, но я полагаюсь на мускуль, который сам проверяет по куке наличие сессии в таблице и создает/апдейтит данные сессии .. так проще :)
 

vovanium

Новичок
для ipv6 на будущее, возможно, переборщил, хватит и 30
а, ню-ню :)

-~{}~ 01.04.09 23:20:

pilot911
так тоже можно, но я полагаюсь на мускуль, который сам проверяет по куке наличие сессии в таблице и создает/апдейтит данные сессии .. так проще
т.е. скорость тебя не волнует? ну тогда ладно :)
 
Сверху