ORM и float: то ли лыжи не едут, то ли...
Суть в чем, у меня при попытке использовать ORM с полями MySQL float ничего не получается. В базу пишутся нули, поскольку DbSimple, послушно следуя локали, преобразует точку в запятую и пытается подсунуть это MySQL, который с гневом это отвергает и записывает ноль. Если без ORM можно подсунуть в параметр буковку 'f', чтобы указать, что поле типа float, то как быть с ORM!?
Вот меня и терзают сомнения — неужели я первый наступаю на эти грабли?
Вот меня и терзают сомнения — неужели я первый наступаю на эти грабли?
12 комментариев
Эээ. Кто поменяет? Сейчас я и выхожу из положения — преобразовываю float в строку и заменяю там запятую на точку. Но это, мягко говоря, извращение.
Соответственно я перед save() сам преобразую поле в строку и насильно меняю запятую на точку, чтобы escape с ней уже ничего не сделало. Но это неправильно жеж.
->save()
->addEntity() [module method]
->addEntity() [mapper method]
тут используется родной mysql_real_escape для mysql либо метод escape() для mysqli (прямо в обертке DbSimple)
То есть перед save оно еще во float, а при эскейпе локаль переводит в строку.
Что если взять при set сделать set((float)$var);
Т.е. DbSimple передается массив пар поле/значение для апдейта. А DbSimple это дело уже самостоятельно оборачивает своим escape. Так, что по-любому надо делать что-то до того, как все это уходит в DbSimple.
Насколько я понимаю, самый простой выход тут определять в ORM сущности еще какой-то массив типа aRelations в котором бы указывались поля с дробной частью (ну или может еще какие «экзотические» типы) и заведение отдельных методов получения значений полей для формирования запросов к БД, которые бы учитывали тип поля.
Я такого ни разу не ожидал, уж ORM в LS давно не свежая штука, а, получается, народ не пользует ее с дробными числами.