Data Director: значне підвищення продуктивності у версії 3.0

У версії 3.0 Blackbit робить великий крок і оснащує Data Director більш ефективним методом зберігання, який робить імпорт значно швидшим, ніж зі стандартною логікою зберігання Pimcore.

Новий, ресурсозберігаючий метод зберігання

Стандартний метод збереження Pimcore не є оптимальним з точки зору продуктивності, оскільки він не тільки зберігає змінені дані, але й перераховує кожен аспект усіх полів класу: Всі поля перевіряються на валідність, щоразу перераховуються залежності тощо. Тож навіть якщо ви змінюєте лише одне поле введення, всі ці кроки обробки будуть виконані.

Ось чому Data Director 3.0 має власний механізм зберігання, який зберігає тільки ті дані, які дійсно змінилися. Цей оптимізований для підвищення ефективності процес зберігання підвищує продуктивність приблизно на 200%.

Оскільки це важлива зміна, після оновлення до версії 3.0 всі існуючі порти даних будуть переведені в так званий "режим сумісності". Це означає, що спочатку вони будуть продовжувати використовувати старий механізм зберігання даних, щоб мінімізувати ризик появи багатьох непрацюючих портів даних. Ви можете вимкнути "режим сумісності" у додаткових налаштуваннях портів даних. Для нових портів даних "режим сумісності" автоматично вимикається, щоб забезпечити оптимальну продуктивність.

Ефективніше завантаження даних з останньої версії

Щоб перевірити, чи змінився об'єкт під час імпорту, попередньо завантажується остання версія об'єкта. Однак, оскільки версії зберігаються у файловій системі в серіалізованому вигляді, цей процес займає багато часу. У версії 3 старі значення зіставлених полів імпорту тепер зчитуються до того, як вони будуть змінені, що робить ресурсоємне завантаження версій зайвим.

Параметризація прогонів портів даних

Тепер ви можете параметризувати всі елементи порту даних:

• Доступ до URL / CLI параметрів у селекторах запитів даних портів даних на основі Pimcore, наприклад, image:thumbnail# повертає шлях до мініатюри визначення "500px", коли доступ до порту даних здійснюється за URL /api/export/dataport-name?format=500px
• Доступ до параметрів URL/CLI у функціях зворотного виклику через . Це дозволяє, наприклад, визначити формат виводу експорту.
• Доступ до URL / CLI параметрів в ресурсі імпорту / умові SQL (існує з версії 2.6)

Тепер також можна отримати доступ до полів класу вихідних даних у селекторах запитів до даних портів даних на основі Pimcore. Наприклад, якщо у вас є селектор запиту даних myMethod#, автоматично використовується номер статті поточного об'єкта класу вихідних даних (якщо параметр URL "номер статті" не перезаписує його). Ви також можете викликати сервісні класи з параметрами: @service_name::method#3108 викликає метод "method" сервісу Symfony "service_name" з ідентифікатором поточного об'єкта вихідного класу.

Імпорт в поля значень, що обчислюються

Тепер можна імпортувати дані в поля значень, що обчислюються, без необхідності створювати додатковий PHP-клас для логіки обчислення. Це може бути застосовано до всіх даних, які повинні використовуватися тільки для відображення, але не для редагування, наприклад, для візуалізації якості даних.

Відображення необроблених даних у звіті Pimcore

У версії 3.0 з'явився адаптер звіту для необроблених даних Dataport. Це має два основних випадки використання:

1. Зробити необроблені дані придатними для повторного використання між декількома портами даних,
2. Спрощення створення звітів, оскільки не потрібні знання SQL/Pimcore баз даних

Запобігання дублюванню активів

За допомогою одного прапорця тепер можна створювати ресурси, тільки якщо вони ще не існують. Це працює, навіть якщо зображення активів мають різні імена файлів або різні розміри зображень.

Зміни в інтерфейсі

Налаштування порту даних

• Покращено автозавершення для селекторів запитів до даних
• Сортування запропонованих селекторів запитів до даних за відстанню Левенштейна до потрібного селектора -> більш релевантне сортування
• при створенні портів даних аналізується ім'я порту даних для визначення типу джерела даних + класу джерела/цілі

Відображення атрибутів

• Мова локалізованих полів відображається у вигляді прапорця для кращої ідентифікації мови локалізованого поля
• Візуалізація залежностей при натисканні на поле відображення атрибутів
• Прискорення генерації шаблонів функцій зворотного виклику
• Оновлення попереднього перегляду залежних полів при оновленні функції зворотного виклику
• Вікно функції зворотного виклику може бути розгорнуто

Панель історії

• Підтримка пошуку за ім'ям файлу журналу порту даних для полегшення доступу до файлу архіву імпорту
• Форматування дати початку відповідно до поточної локалі користувача (на основі мовних налаштувань користувача)
• Нове вікно не відкривається, якщо функція зворотного виклику результату не генерує жодного результату (наприклад, для імпорту, який викликає залежний імпорт)

Селектори вилучення необроблених даних/запиту даних

• Попередження спрацьовує, якщо CSV/Excel файл містить один і той самий заголовок стовпця кілька разів.
• Підтримка селектора ":url" для полів ресурсів і зображень для отримання абсолютної URL-адреси призначеного ресурсу (ресурсів).
• Підтримка пошуку зворотних зв'язків через Category:products: якщо клас Category керує зв'язком з продуктами, а клас вихідних даних експорту - Product.
• Підтримка "предків" / "нащадків" у селекторах запитів даних для отримання всіх об'єктів вище / нижче поточного об'єкта.
• Підтримка фільтрації масивів у селекторах запитів даних, наприклад, зв'язок "багато-до-багатьох" можна відфільтрувати за категоріями за допомогою категорій:filter#published,true, щоб отримати лише опубліковані об'єкти відповідних категорій.
  Інший випадок використання: якщо у вас є колекція полів з цінами і датами їхньої дії, ви можете використовувати prices:filter#validFrom,now,>=:filter#validTo,now,<=, щоб отримати всі елементи колекції полів, які є дійсними на сьогодні.
• Підтримка допоміжних функцій "withInheritance" / "withoutInheritance" для ввімкнення / вимкнення успадкування для окремих селекторів запиту даних
• Підтримка суфіксальних псевдонімів у селекторах запитів до даних, наприклад, (скаляр;об'єкт:скаляр) як group1

Обробка вихідних даних

• Надання $params['transfer'] також для функцій зворотного виклику полів
• Підтримка пошуку реляційних об'єктів за унікальним індексом: не потрібно повертати селектор запиту даних "Виробник:Назва:".$params['value'], якщо поле "Назва" в класі "Виробник" є унікальним. У цьому випадку достатньо присвоїти назву виробника як поле необроблених даних.
• Підтримка пошуку декількох об'єктів за допомогою селекторів запиту даних
• Потокова передача документів результатів мінімізує споживання пам'яті навіть при створенні великих експортних документів (наразі реалізовано тільки для CSV).
• Виправлення: ключ об'єкта був недійсним, якщо ключ мав довжину 255 символів і об'єкт з таким самим ключем вже існував. Довжина суфікса тепер віднімається, щоб повернутися до 255 символів.
• Додано можливість автоматичного створення полів сховища класифікаторів
• Підтримка автоматичного створення тексту через OpenAI API
• Підтримка прив'язки мови до постачальника перекладу, наприклад, використання en-gb як цільової мови для "en".
• При перезапуску Dataport через ненавмисне скасування, система перевіряє, чи можна продовжити роботу Dataport: Неінкрементний експорт не може бути продовжений і повинен бути повністю перезапущений. Імпорт та інкрементний експорт можна продовжувати, як і раніше.
• Підтримка присвоєння елементів метаданих активів (раніше підтримувався лише тип "вхідний").
• Виправлення: обробка віртуальних полів, які використовуються в ключових полях

Інші зміни

• Видалення необроблених даних виконується пакетами, оскільки великі процеси видалення в іншому випадку займали б занадто багато часу.
• Реструктуризація журналювання для більш ефективного використання пам'яті.
• Видалено spatie/once, оскільки це спричиняло багато непотрібних викликів debug_backtrace().
• Журнали у логері програми згруповано: Певні повідомлення перелічено лише один раз і позначено індексом частоти, наприклад, "сталося 3 рази".
• Селектор запиту даних Product:articleNo:.:name#en для визначення поточного значення поля "articleNo" більше не підтримується. Це пов'язано з тим, що цей селектор запиту даних призначений для пошуку товарів з articleNo=".". Ви можете використовувати $params['currentObjectData']['articleNo'] для отримання поточного значення поля "articleNo".
• Автоматичне виправлення неправильно налаштованих часових поясів за замовчуванням між PHP веб-сервера і CLI PHP, завжди зберігаючи дані в UTC. В іншому випадку запуск Dataport може бути скасовано, оскільки він триває занадто довго, або на панелі історії відображається від'ємний час виконання тощо.
• Виправлено: Сповіщення про те, що процесор черги не вдалося запустити, також надсилалося, якщо процесор черги було запущено, але він завершив роботу менш ніж за 5 секунд.
• Автоматичне перезавантаження елементів, якщо вони були змінені автоматичним імпортом після збереження.
• Пропуск перевірки хешу для імпорту на основі pimcore
  Варіант використання: Автоматичний імпорт, який встановлює опубліковані об'єкти на основі певної логіки полів вихідних даних.
  
  • 1-й прохід: об'єкт публікується -> логіка імпорту встановлюється на false -> хеш необроблених даних зберігається -> об'єкт зберігається і повторно публікується без змін
  • 2-й прохід: сирі дані ті самі -> але опубліковані були змінені -> ми повинні запустити Dataport знову, інакше об'єкт буде опублікований, хоча опублікована логіка мала б його не публікувати.
• Підтримка різних контекстів запитів, щоб мати можливість змінювати поведінку перезаписаних методів отримання.
• При перейменуванні портів даних усі перенаправлення для старих URL-адрес кінцевих точок REST API цього порту даних вказують на нову URL-адресу. Це запобігає виникненню ланцюжків редиректів.
• Виправлення: повідомлення про блокування редагування більше не з'являється, якщо поточний користувач щойно зберіг об'єкт.
• Дія документа результату "Надіслати поштою" підтримує надсилання документів-відповідей як вкладень.
• Виправлено: Автоматичний запуск не працював для імпорту з Excel.
• Більш ефективне видалення тимчасових файлів після кожного блоку необроблених даних. За замовчуванням вони видаляються тільки після завершення всього процесу, що витрачає багато пам'яті.
• Виправлено: очищення файлів журналу логів програми працювало некоректно.
• Логування користувача, який запустив запуск Dataport.
• Видалено автоматичне налаштування того, що завантажені вручну файли повинні використовувати ресурс датапорта "за замовчуванням". Замість цього для завантаженого файлу створюється окремий ресурс. Наслідок: якщо порт даних запускається з тим самим файлом, попередній файл перезаписується, а ім'я файлу відображається на панелі історії замість згенерованого uniqid().
• Кілька елементів необроблених даних більше не обробляються в одній транзакції бази даних, оскільки проблема з одним елементом могла б перешкодити імпорту всіх інших елементів у тій самій транзакції.

Blackbit Data Director на YouTube

Ви вже знайомі з нашими відеоуроками по Data Director? Щоб отримати корисні поради та детальну інформацію про застосування, відвідайте сторінку Blackbit на YouTube!

Все ще маєте запитання?

Вам цікаво і ви хотіли б дізнатися більше про наш Data Director? Зв'яжіться з нами зараз, і ми покажемо вам у безкоштовній демо-версії, які можливості відкриває для вас Data Director.