Спасибо. Но раз такая пьянка, вопрос второй — если в одной строке расположить селект и кнопку (скажем, действия с выделенными в таблице абонентами — селект — что делать, кнопка — отправка запроса), обернутые в бтн-груп и правее еще одну кнопку (например — новый абонент), то вертикально они будут выровнены по разному. Почему так получается, и как с этим бороться? Пока вношу margin-top:-11px, но это зло.
container есть, он выше ))
Я вот row понять не могу, он отступы как я понял на корню убивает. Если div class='spanx' имеет внутренние отступы, то если оборачиваешь в row, улетает влево.
Наверху пунктирные линии — логические связи, еще есть слой оптики и муфт, но не отображен. Это директорский вариант. Светлые точки на некоторых коммутаторах — наличие ups.
На линиях подписывается с какого порта в какой идет подключение.
Имена коммутаторов в нашем случае сформированы как часть ip+суффикс модели.
Вот сейчас во внутренней разработке у нас за каждым адресом, который подключен к интернету (работаю в телекоме), числится gid здания из osm (данные из osm импортируем каждую ночь), и любую правку здания отслеживаем автоматически — будь то смещение дома на карте (необходимо коммутатор на карте сместить относительно смещения здания) или же полное удаление (такого, как правило, не случается). Так вот если происходит удаление, то происходит и рисование, ведь у нас в этом доме есть абоненты, и о физическом «удалении» здания мы узнаем сразу.
Конечно Вы можете считать меня параноиком, но вариант, при котором скрипты сами следят за изменениями, мои скрипты — для меня более приемлем, нежели полагаться на результат запроса «Воронеж, Лизюкова, 4».
Яндекс карты в последнее время не плохи, но в случае использования их нет никаких гарантий, что дом просто не сотрут. И потом, получение здания происходит поисковым запросом, если можно так сказать, а нужно один раз проверить адрес и дом, связать их между собой и периодически проверять на корректировки.
Администратор БД полностью против этого — далеко не все устройства в этой таблице редактируемы, и в половине случаев поле не нужно. Было временное решение — в поле devices.users вносили нужное значение, а триггер анализировал новое значение на определенные условия и выполнял те или иные действия.
Вы повторяете то, что уже триггером описано. В логе несколько полей — type, message, mac, sn, old_val, new_val (и другие). Сейчас вот и uid добавил.
Так вот, я и говорю, в лог пишут триггеры. Событий МНОГО: изменение расположения устройства, включение-выключение портов, изменение в конфиге, отправка на склад, в ремонт, возврат, перенос между филиалами и т.д. и т.п.
Все события срабатывают через объект класса device. Но Вы сейчас предлагаете повторить код триггеров еще и здесь. Этого нужно избежать. Есть триггеры и всё. Намного проще (даже с учетом на будущее расширение системы) добавить в запросы параметр user_id.
