Czy ten test kiedykolwiek failował ?

Stąd moje pytaniefracz pisze: ↑pt sty 24, 2020 10:41 amTak. Wcześniej ORM zwracał longi i były one konwertowane po stronie klienta (co powodowało problem). Teraz od razu zwraca adres kropkowo-dziesiętny, przekonwertowany przez INET w bazie danych
Oczywiście zakładając że 32-bitowy MySQL sobie z tym radzi...Niestety nie da się na Travisie odpalić testów w x32.
Dzięki łaskawco
MySQL rozumie typy ze znakiem i bez znaku. Dlatego mysql na 32-bitach potrafi poprawnie skonwertować wartość dziesiętną ipv4 na tekst w formacie x.x.x.xklew pisze: ↑pt sty 24, 2020 10:47 amStąd moje pytaniefracz pisze: ↑pt sty 24, 2020 10:41 amTak. Wcześniej ORM zwracał longi i były one konwertowane po stronie klienta (co powodowało problem). Teraz od razu zwraca adres kropkowo-dziesiętny, przekonwertowany przez INET w bazie danych
Oczywiście zakładając że 32-bitowy MySQL sobie z tym radzi...Niestety nie da się na Travisie odpalić testów w x32.
. Skoro test nigdy nie failował, to skąd wiesz, że naprawia problem?
![]()
Nie no, wcześniej ta asercja by nie przeszła, bo wartością zwróconą z tej metody był long. Więc upewnia się, że baza danych teraz to konwertuje, ale nie upewnia się że robi to dobrze