Розбіжності

Тут показані розбіжності між вибраною ревізією та поточною версією сторінки.

--- migration2_exten [2024/10/01 17:20]
bobr
+++ migration2_exten [2024/10/01 18:02] (поточний)
bobr [Структура файлу імпорту]
@@ Рядок 1: / Рядок 1: @@
 ====== Міграція абонбази 2 - "РОЗШИРЕНА" ======
-Починаючи з релізу 1.3.1 доступна так звана "РОЗШИРЕНА" версія модуля [[migration2|"Міграція 2"]], яка трохи більше, ніж повністю базується на методі імпорту "Ubilling live register", що в свою чергу зумовлює використання "стандартного режиму реєстрації абонента в Ubilling", з безпосереднім залученням Stargezer'у до цього процесу(що накладє певні обмеження, про які буде сказано пізніше). \\
+Починаючи з релізу 1.3.1 доступна так звана "РОЗШИРЕНА" версія модуля [[migration2|"Міграція 2"]], яка трохи більше, ніж повністю базується на методі імпорту **"Ubilling live register"**, що в свою чергу зумовлює використання "стандартного режиму реєстрації абонента в Ubilling", з безпосереднім залученням Stargazer'у до цього процесу(що накладє певні обмеження, про які буде сказано пізніше). \\
 Головною відмінністю цієї "версії" мігрувалки є:
   * опціональна можливість "повноцінного заселення" абонів безпосередньо в процесі міграції - тобто так - створення населених пунктів, вулиць, будинків прямо "на льоту"
@@ Рядок 10: / Рядок 10: @@
   * використання значень за замовчуванням для певних полів імпорту, якщо даних для цих полів нема у CSV файлі
   * можливість генерації рандомних значень для полів: **login**, **password**, **MAC address**
+  * можливість пропуску довільної кількості рядків від початку CSV файлу
   * неможливість використовувати будь-який інший метод імпорту, окрім "Ubilling live register"
@@ Рядок 19: / Рядок 20: @@
 Власне, базується на структурі для [[migration2|"Міграція 2"]], але, як вже мабуть зрозуміло - є дещо розширеною 8-) \\
 Отож, на скріншоті нижче ви можете бачити всі поля даних, які може бути імпортовано. Так, всі-всі, аж до **Target network** - це поле і все, що нижче за ним - **не є полями імпорту**.
-{{ migration2exten13.jpg }}
+{{ migration2exten13.jpg }} \\
+Тобто створюєте свій CSV файл з даними з вашої БД у будь-який зручний для вас спосіб і "проектуєте" його так, щоб у ньому містилися поля, інформація в яких "задовольнить" максимальну кілкість полів імпорту - таким чином отримуєте максимально можливий профіт від процесу міграції і мінімізуєте "мануальні маніпуляції руками" у подальшому.
 ===== Маппінг полів імпорту до полів CSV файлу =====
@@ Рядок 27: / Рядок 29: @@
 Нижче, під табличкою, побачимо вже знайомі нам випадаючі списки з номерами наших полів(якраз тому **дуже рекомендовано** щоб у найпершому рядку вашого CSV файлу містилися саме **осмислені найменування полів даних** - хоча це і необов'язково). \\
 Далі - все просто - вибираєм у випадаючих списках номери полів CSV файлу які містять дані для кожного з полів імпорту. За необхідності(або при відсутності даних для цих полів у вашому CSV файлі) - для більшості полів імпорту можна вказати значення за замовчуванням, які будуть використані для кожного рядка файлу імпорту: \\
-{{migration2exten5.jpg?350x200}} {{migration2exten6.jpg?350x200}} {{migration2exten7.jpg?350x200}} {{migration2exten8.jpg?350x200}} {{migration2exten9.jpg?350x200}} {{migration2exten10.jpg?350x200}}
+{{migration2exten5.jpg?350x200}} {{migration2exten6.jpg?350x200}} {{migration2exten7.jpg?350x200}} {{migration2exten8.jpg?350x200}} {{migration2exten9.jpg?350x200}} {{migration2exten10.jpg?350x200}} \\
+і так - **Залишити пустим** - теж своєрідне значення "за замовчуванням"(детальних пояснень тут, сподіваємося, не треба?). \\
+==== IP-мережа ====
+Якщо у випадаючому списку **NAS IP address** буде вказано номер поля з файлу імпорту - скрипт буде намагатись для даного абонента автоматично визначити мережу у вашому поточному Ubilling інстансі. Працює все доволі просто: беремо IP NAS'у, шукаємо мережу з таким NAS'ом і беремо її **ID** - все. Якщо нічого не було знайдено - використовуємо мережу вказану у наступному випадаючому списку **Target network** - тобто списку мереж вашого Ubilling інстансу: \\
+{{migration2exten11.jpg}}
-"Ubilling live register" накладає такі обмеження
+===== Фінальний контроль =====
-  * строга вимога до коректності структури файлу імпорту та, власне, імпортованих даних: так, зайві символи-делімітери або "кракозябри" в даних можуть призвести до фатальної помилки в процесі виконання скрипта, яка призведе до зупинки процесу імпорту "десь посеред дороги" і вгадувать потім, які записи було імпортовано, які ні, а які було імпортовано частково - вам доведеться самостійно, витративши чимало часу(це гарантовано на 88.88%)
+Після завершення проставляння відповідностей між полями імпорту та полями CSV файлу переходимо на форму "фінального контролю", таку ж як і у "попреденіх міграцій". Зупинимось на її елементах управління:
-  * неможливість імпортувати всю вашу БД з CSV файлу розміром кілька гіг: так, оскільки імпорт кожного запису займає певний час, то виконання всього скрипта може банально впертися в ліміт **max_execution_time**, а використання **set_time_limit(0)** як потенційного лайфхаку швидше за все банально приведе до **HTTP timeout** - тому **розділяйте** свою БД на кілька CSV файлів за якимись ознаками, типу місто, вулиця, тег, IP-мережа, etc
+{{migration2exten12.jpg}} \\
+Отож, кнопка
+  * **Ні, я хочу спробувати інші налаштування імпорту** - поверне вас на **самий початок**, до вибору CSV файлу
+  * **Yes, proceed registration of this users (no occupancy and tags will be created)** - запустить імпорт без створення населених пунктів, вулиць, будинків, а також без створення та асоціювання тегів
+  * **Yes, proceed registration of this users and create occupancy and tags if not exists** - запустить імпорт зі створенням населених пунктів, вулиць, будинків, а також тегів та їх асоціювання до абонів
+===== Обмеження =====
+Метод імпорту **"Ubilling live register"** накладає такі обмеження
+  * строга вимога до коректності структури файлу імпорту та, власне, імпортованих даних: так, зайві символи-делімітери або "кракозябри" в даних можуть призвести до фатальної помилки в процесі виконання скрипта, яка призведе до зупинки процесу імпорту "десь посеред дороги" і вгадувать потім, які записи було імпортовано, які ні, а які було імпортовано частково і "викусювати" то з CSV файлу - вам доведеться самостійно, витративши чимало часу(це гарантовано на 88.88%)
+  * неможливість імпортувати всю вашу БД з CSV файлу розміром кілька гіг одразу за раз: так, оскільки імпорт кожного запису займає певний час, то виконання всього скрипта може банально впертися в ліміт **max_execution_time**, а використання **set_time_limit(0)**, як потенційного лайфхаку, швидше за все банально приведе до **HTTP timeout** - тому **розділяйте** свою БД на кілька CSV файлів за якимись ознаками, типу: місто, вулиця, тег, IP-мережа, etc

Ubilling Wiki

Користувальницькькі налаштування

Налаштування сайту

Розбіжності

Налаштування сторінки