Nieprawidłowy adres IP w aplikacji klienckiej

[klew]

W nagrodę Twój adres zostanie w źródłach Supli na zawsze

Czy ten test kiedykolwiek failował ?

[fracz]

Tak. 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.

[klew]

Tak. 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.

Stąd moje pytanie . Skoro test nigdy nie failował, to skąd wiesz, że naprawia problem?

[Goral64]

W nagrodę Twój adres zostanie w źródłach Supli na zawsze

Dzięki łaskawco Ale to adres przydzielany dynamagicznie z Neostrady, więc byłe ze mną niecałą dobę

[pzygmunt]

Tak. 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.

Stąd moje pytanie . Skoro test nigdy nie failował, to skąd wiesz, że naprawia problem?

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.x

[fracz]

Stąd moje pytanie . 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

[fracz]

Niezawodny SUPLA TEAM wydał v2.3.18.

Sprawdź proszę czy po aktualizacji adresy IP wyświetlają się poprawnie