Т.е., если я правильно понимаю, честного, в полном смысле, способа нет? В обоих системах нужно это делать через программу тестирования?
Хотелось, конечно, решения, максимально простого для пользователей, чтобы каждому из нескольких сотен сотрудников не требовалось производить у себя на девайсе каких-либо манипуляций, кроме привычного скачивания приложения.
Жаль, если это единственный путь. И, на самом деле, удивительно, задача ведь подобная должна встречаться достаточно часто.
Я говорю абсолютно серъезно. Своими проектами надо заниматься дома, а на работе надо работать :). Если програмирование вам в радость, то силы для себя вечером будут :)
Flie: Понятие "синиора" в каждой кампании отличается, поэтому можно уложиться и в полгода, а можно и в пять лет :). Разумеется, "синиоры" получатся при этом совершенно разные.
Самому можно, но сложно, поскольку масса знаний добывается из личного опыта своего и коллег, и одними статьями в интернете обойтись сложно.
Ну я думаю если сервер найден и там просто урл не найден или не ответил то точно будет или 500 или 403 или 404.
Конкретно в этом случае - да. Но, к примеру, когда Java приложение деплоится, оно может быть недоступно совсем-совсем. Там уже корректного кода не будет. Или (если о мобильных говорить) - инет отвалился :). Это не всегда заметно пользователем.
Но и потом с чего вы взяли что при переходе по страницам будет опять срабатывать запрос
Не знаю, с чего взял - я про это вообще не писал :). Речь шла о том, что при смене страницы при активном запросе через $http, будет вызван обработчик error со status = 0. Пользователю о таких прерванных запросах знать не обязательно, в отличие от запросов, завершившихся с точно такой же ошибкой в случае недоступности API. Дело за малым - найти 10 отличий в обработке этих ситуаций :(
Проблема не столько в том, чтобы определить недоступность сервера (да, error + status = 0 это, возможно, и будет означать), сколько в том, чтобы отфильтровать ложные срабатывания ошибки, например, просто в случае смены страницы. И в этом случае игнорировать ошибку, не пугая пользователя алертами о недоступности сервера.
Если не ошибаюсь, в jquery есть readyState и с помощью его (вместе с проверкой статуса) удавалось всё грамотно разруливать. Но вот Angular...
Несколько потоков вполне возможны, но разве это причина для несрабатывания ограничения? :)
Собственно, из-за конкуренции так и было сделано (да, INSERT/UPDATE).
Мы, вероятно, перепишем (т.к. иначе непонятно как решить проблему), но всё-таки хочется понять, что вообще происходит, и что приводит к дубликатам. Это же теряется весь смысл уникальных ограничений, если такой треш возможен (если предположить, что это баг PG).
