Neomodel Python OGM: Глибоке занурення в моделювання Neo4j

Головна » Python » Neomodel Python OGM: Глибоке занурення в моделювання Neo4j

Neomodel — це інструмент для відображення об'єктів-графів Python (OGM), розроблений для того, щоб робота з Neo4j була такою ж природною, як і написання звичайного коду Python. Замість того, щоб постійно вручну створювати запити Cypher, ви описуєте свій графовий домен за допомогою класів, полів та зв'язків, а neomodel обробляє зіставлення між об'єктами Python та вузлами та зв'язками Neo4j. Він побудований на основі офіційного драйвера Neo4j Python, лише з тонким шаром абстракції, тому ви отримуєте високий рівень зручності без значних жертв продуктивності.

Як частина екосистеми Neo4j Labs, neomodel активно підтримується, повністю підтримує сучасні версії Python та Neo4j, а також пропонує як синхронні, так і асинхронні API. Він пропонує знайомі, подібні до Django визначення моделей, багатий API запитів, застосування схеми через кардинальність, вбудовані транзакції та тісну інтеграцію з Django через django_neomodelВодночас, він залишається майже повністю функціональним: ви завжди можете перейти на чистий Cypher, коли цього вимагає продуктивність або складність запитів.

Що таке неомодель і чому вона важлива

Neomodel — це Object Graph Mapper для графової бази даних Neo4j, що поєднує класи Python та графові структури. Замість ручного створення вузлів та зв'язків за допомогою рядків Cypher, ви визначаєте класи Python, які представляють ваші сутності домену, а neomodel перетворює їх на позначені вузли з індексованими властивостями та обмеженнями в Neo4j. Він базується на офіційному neo4j-python-driver, тому його поведінка відповідає тому, що ви б робили, використовуючи драйвер безпосередньо.

Бібліотека зосереджена на знайомому стилі моделювання на основі класів з надійним успадкуванням, перехопленнями та валідацією. Такий підхід робить його особливо зручним для розробників, які звикли до Django ORM або інших Python ORM: атрибути ваших класів моделі відповідають властивостям у Neo4j, тоді як спеціальні поля зв'язків фіксують ребра графа. Завдяки такій конфігурації обхід графа стає питанням відстеження атрибутів об'єктів, замість того, щоб щоразу писати багатослівний Cypher.

Під капотом neomodel пропонує потужний API запитів, який охоплює поширені шаблони доступу до графів, не змушуючи вас одразу переходити до «сирого» Cypher. Ви можете фільтрувати, упорядковувати, проходити між зв'язками, розрізати набори вузлів та виконувати розширені операції через інтерфейс Pythonic. За потреби ви все ще маєте доступ до cypher_query помічник для виконання користувацьких запитів та безпосередньої роботи з повернутими результатами.

Ще однією центральною особливістю є забезпечення дотримання схеми за допомогою правил кардинальності для зв'язків та обмежень властивостей. Вказуючи кардинальність (наприклад, нуль або більше, один або більше або один) безпосередньо в полях зв'язків, ви можете забезпечити структурні очікування у вашому графі та дозволити neomodel допомогти вам уникнути невідповідних даних. Індекси та обмеження створюються автоматично на основі визначень моделі, а також існують утиліти CLI для їх контрольованого застосування або видалення з бази даних.

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

Підтримка версій, SemVer та конфігурація

Сучасні неомодельні релізи дотримуються семантичного версіонування (SemVer) з використанням класичного шаблону major.minor.patch. Це означає, що критичні зміни впроваджуються лише разом із основними оновленнями версій, нові функції без критичної поведінки з'являються як другорядні релізи, а виправлення помилок постачаються як патчі. Така стратегія керування версіями спрощує планування оновлень, особливо для виробничих систем.

У серії 6.x neomodel орієнтований на найновіші версії Python та Neo4j, щоб відповідати тим, що використовуються в більшості серйозних розгортань. Зокрема, neomodel 6.x вимагає Python 3.10 або новішої версії та підтримує Neo4j 5.x, Neo4j 4.4 LTS та новішу лінійку Neo4j 2025.xx. Підтримуються як Neo4j Community, Neo4j Enterprise, так і Neo4j Aura (розміщений сервіс), що надає вам гнучкість у тому, як і де розміщувати базу даних.

Для старіших середовищ попередні гілки neomodel все ще охоплюють застарілі комбінації Python та Neo4j. Лінійка 5.x підтримує Python 3.8+ з Neo4j 5.x та 4.4 (LTS), тоді як лінійка 4.x охоплює Python з 3.7 по 3.10 та Neo4j 4.x, включаючи 4.4 LTS при використанні neomodel 4.0.10. Така історія сумісності дозволяє поступово переходити вперед, зберігаючи при цьому ваші існуючі налаштування.

Починаючи з neomodel 6, конфігурація обробляється через сучасний, анотований типами клас даних з перевіркою під час виконання та підтримкою змінних середовища. Замість розрізнених спеціальних налаштувань, поля конфігурації перевіряються під час оновлення, включаючи перевірки типів та логічні обмеження. Змінні середовища можна використовувати для легкого перевизначення конфігурації, що чудово поєднується з контейнерними розгортаннями та хмарними середовищами.

У випуску 6.0 також представлено явні зміни, що призводять до порушень, та виправлення поведінки, щоб зробити API більш передбачуваним. Наприклад, розв'язання списку з Cypher тепер повертає очікувану глибину: запит типу RETURN collect(node) буде зіставлено з results[0][0] замість попереднього, неінтуїтивного results[0][0][0] структура. Перевірки кардинальності суворіші та ввімкнені за замовчуванням, а кілька автономних допоміжних функцій було переміщено до центрального Database() та AsyncDatabase() однотонних класів.

Встановлення та налаштування

Рекомендований спосіб встановлення neomodel – безпосередньо з PyPI за допомогою вашого вибраного менеджера пакетів. Ви можете додати його до віртуального середовища за допомогою простої команди встановлення, а потім керувати оновленнями за допомогою звичайних інструментів керування залежностями. Якщо вам потрібні найновіші зміни або ви хочете зробити свій внесок, також можна встановити його безпосередньо з репозиторію GitHub.

Перш ніж запускати будь-який код neomodel, необхідно налаштувати URL-адресу підключення, щоб бібліотека знала, як зв'язатися з вашим екземпляром Neo4j. Ця конфігурація зазвичай включає схему (Bolt або Neo4j), хост, порт, ім'я користувача, пароль та необов'язкову назву бази даних. Для проектів Django ця конфігурація зазвичай розміщується в settings.py тому він ініціалізується одразу після запуску програми.

Якщо ваш сервер Neo4j нещодавно встановлено, вам слід змінити пароль за замовчуванням за допомогою браузера або панелі адміністратора Neo4j. За замовчуванням ця панель доступна за адресою http://localhost:7474Після оновлення пароля та його підтвердження dbms.security.auth_enabled=true У конфігурації бази даних ви готові до підключення з neomodel.

Для розробки та тестування зазвичай використовуються окремі бази даних Neo4j та виділені облікові дані. Власний тестовий набір Neomodel очікує базу даних Neo4j 4+ та покладається на певні змінні середовища для підключення. Якщо ви запускаєте тести на абсолютно новій базі даних, тестовий набір встановить пароль test за замовчуванням; якщо він виявить існуючий набір даних, він відмовиться продовжувати, якщо ви явно не передасте прапорець скидання, що допоможе вам уникнути випадкової втрати даних.

Якщо ви хочете протестувати neomodel на кількох версіях Python та Neo4j, Docker та docker-compose можуть автоматично все оркеструвати. Проєкт забезпечує конфігурацію для запуску матриці версій інтерпретатора та релізів Neo4j, щоб інтеграційні тести могли виконуватися послідовно. Це особливо корисно, якщо ви додаєте функції, які повинні працювати в кількох підтримуваних версіях.

Основні функції: моделі, схеми та індекси

Серце Neomodel лежить у його визначеннях моделей на основі класів, які безпосередньо відображаються на мітки та зв'язки вузлів Neo4j. Зазвичай ви отримуєте свої класи вузлів з StructuredNode, та класи зв'язків з StructuredRelПоля вузлів визначаються за допомогою специфічних для neomodel типів властивостей, які контролюють, як дані зберігаються та перевіряються в Neo4j.

Кожен клас моделі стає міткою в Neo4j, а neomodel автоматично керує індексами та обмеженнями на основі ваших визначень. Це означає, що унікальність, обов'язкові властивості та індексовані поля можна вказати в Python без необхідності вручну створювати команди Cypher для створення схеми. Незалежно від того, як це працює, neomodel перетворює метадані вашої моделі у відповідні операції схеми Neo4j.

Зв'язки прив'язуються до класів вузлів за допомогою спеціальних дескрипторів, таких як RelationshipTo, RelationshipFrom та Relationship. Ці дескриптори визначають тип зв'язку, кардинальність та напрямок обходу. RelationshipTo та RelationshipFrom виражати односпрямовану навігацію з точки зору Python, тоді як Relationship використовується, коли ви хочете розглядати зв'язок як навігаційний в обох напрямках з коду, навіть якщо сам Neo4j завжди зберігає зв'язки з напрямком.

Коли зв'язки логічно двонаправлені, рекомендується уникати створення двох дзеркальних полів і використовувати одне Relationship замість цього. Це зберігає вашу модель чистою та узгодженою, водночас дозволяючи перехід в обох напрямках у вашому коді Python. Neo4j все ще зберігатиме спрямоване відношення "під капотом", але абстракція neomodel приховує цю деталь під час переходу.

Для сценаріїв, де структури вузлів не повністю відомі заздалегідь, neomodel пропонує SemiStructuredNode базовий клас. Класи, похідні від цього типу, можуть містити «спеціальні» властивості, які не були явно визначені в моделі. Це особливо зручно, коли ваша схема графа часто змінюється або коли вам потрібно додавати додаткові атрибути без рефакторингу моделі кожного разу.

Правила кардинальності визначають кількість допустимих зв'язків між вузлами та тепер підкріплюються суворішими перевірками в neomodel 6. М’які перевірки кардинальності доступні для всіх кардинальностей зв’язків, а сувора перевірка ввімкнена за замовчуванням. Якщо ваші дані порушують налаштовані правила зв’язків, neomodel виявить цю проблему, а не дозволить непослідовній структурі мовчки зберігатися.

Автоматичне керування та перевірка схем

Після визначення або оновлення моделей вам потрібно застосувати відповідні обмеження та індекси до бази даних Neo4j. Neomodel постачається зі скриптом під назвою neomodel_install_labels який сканує ваші моделі та створює або оновлює необхідні індекси та обмеження. Після зміни схеми слід запустити цей скрипт і переглянути кількість оброблених класів, щоб переконатися, що все синхронізовано.

Якщо вам коли-небудь знадобиться видалити обмеження та індекси, якими керує neomodel, існує додаткова команда під назвою neomodel_remove_labels. Цей скрипт автоматично видаляє всі існуючі обмеження та індекси, які neomodel встановив раніше. Він також виводить те, що було видалено, щоб ви чітко бачили вплив операції.

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

Окрім створення схеми, neomodel включає інструмент перевірки бази даних, який може виконати зворотне проектування існуючого графа та згенерувати файл моделі. Використання inspect команду (яка вимагає встановлених процедур APOC у Neo4j), ви можете просканувати базу даних та створити models.py файл у цільовому каталозі, такому як yourappЗгенерований файл містить імпортовані дані, визначення класів вузлів та визначення зв'язків, що відповідають виявленій структурі графа.

Процес перевірки можна налаштувати для великих графів, пропускаючи властивості зв'язків та сканування кардинальності. Для баз даних із сотнями тисяч вузлів та понад мільйоном зв'язків повне сканування може тривати десятки секунд. Такі опції, як --no-rel-props та --no-rel-cardinality пришвидшити процес, пропустивши детальний аналіз, все ще генеруючи поля зв'язків, але встановлюючи за замовчуванням загальне значення, таке як ZeroOrMore.

Робота з neomodel Query API

API запитів Neomodel дозволяє виконувати багаті запити до графів за допомогою методів Python у класах моделей, а не писати Cypher безпосередньо. Кожна модель виявляє .nodes атрибут, подібний до менеджера, який представляє набір вузлів з відповідною міткою. Звідти ви можете підраховувати, фільтрувати, упорядковувати, розрізати та отримувати дані графа, що лежать в основі.

покликання len(MyModel.nodes) запускає запит Cypher, який підраховує вузли з міткою, що відповідає MyModel. Це пропонує інтуїтивно зрозумілий спосіб отримання підрахунків, не виходячи з синтаксису Python. Якщо ваш набір вузлів вже відфільтровано, підрахунок відображатиме лише ті вузли, які відповідають цим фільтрам, що відповідає поведінці, яку ви очікуєте від типового ORM.

Розділення підтримується безпосередньо на наборах вузлів, що надзвичайно корисно, коли потрібно працювати з пакетними результатами. Вирази типу MyModel.nodes[0:10] повертає зрізаний набір вузлів, який можна перебирати або далі об'єднувати з додатковими фільтрами. Зріз повертає не одразу сирий список, а інший об'єкт набору вузлів, тому можна створювати складні запити крок за кроком.

Набори вузлів підтримують ітерації та логічні перевірки, хоча операції з довжиною та істинністю є термінальними. Як тільки ви оціните len() або використовуючи набір вузлів у булевому контексті, ви фактично запускаєте крок оцінки, який повертає конкретний результат, а не ще один об'єкт запиту, що може бути з'єднаний у ланцюжок. Такий дизайн поєднує ідіоми Python з лінивою природою побудови запитів.

Для отримання фактичних об'єктів зазвичай використовуються такі методи, як .all() та .get() на .nodes менеджером. Ці методи можуть отримати lazy=True аргумент для повернення лише ідентифікаторів вузлів замість повних об'єктів та всіх їхніх властивостей. Це корисно, якщо ви хочете мінімізувати передачу даних або виконувати подальші запити вручну на основі ідентифікаторів.

Створення, оновлення, видалення та зв'язки

Створення вузлів за допомогою neomodel таке ж просте, як створення екземпляра вашого класу моделі та виклик save(). Після визначення властивостей та значень за замовчуванням можна створити екземпляр із потрібними значеннями полів, викликати save, а neomodel створить або оновить відповідний вузол у Neo4j. Це аналогічно тому, як більшість ORM обробляють персистенцію.

Оновлення вузлів відбувається за тією ж схемою: отримання екземпляра, призначення нових значень його атрибутам та повторне збереження. Neomodel бере на себе генерацію правильного шифру (Cypher) для зміни лише змінених властивостей існуючого вузла. Такий підхід забезпечує простоту коду та не враховує деталі операцій оновлення у вашій бізнес-логіці.

Видалення вузла також є прямим: як тільки у вас є екземпляр, ви викликаєте його delete() метод. Це видаляє вузол і, залежно від конфігурації зв'язків та обмежень бази даних, може також видаляти приєднані зв'язки. Для більш розширеної поведінки або ведення журналу можна визначити перехоплення перед видаленням та після видалення.

Зв'язки між вузлами керуються за допомогою полів зв'язків та зручних методів, таких як connect(). Як тільки у вас буде два вузли, ви можете викликати щось на кшталт actor.movies.connect(movie) щоб створити відповідний екземпляр зв'язку в графі. Властивості зв'язку можна моделювати за допомогою StructuredRelкласи на основі , що також дає вам місце для зберігання атрибутів на ребрах.

Складніші обходи графів можна досягти, дотримуючись атрибутів зв'язків або комбінуючи фільтри запитів між зв'язками. Наприклад, ви можете почати з Entity набір вузлів, фільтрувати за певною властивістю, а потім переходити до пов'язаних вузлів, щоб фільтрувати також за їхніми атрибутами. Це поступово створює запит Cypher під капотом, який neomodel виконує від вашого імені.

Асинхронна неомодель та API синхронізації транспіляції

Neomodel включає асинхронну підтримку, побудовану на основі асинхронних можливостей офіційного драйвера Neo4j Python. Це означає, що ви можете інтегрувати операції Neo4j у сучасні асинхронні фреймворки та сервіси Python, використовуючи всі переваги паралельності для робочих навантажень, що передбачають багато операцій вводу/виводу.

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

Внутрішньо neomodel підтримує узгодженість API асинхронізації та синхронізації за допомогою кроку транспіляції, який перетворює асинхронний код на його синхронний еквівалент. Для автоматичного зачищення використовується спеціальна бібліотека await ключові слова, перейменувати класи (наприклад, видалити Async префікси) та виконувати цільові заміни, такі як зміна adb до db or mark_async_test до mark_sync_testТакий підхід дозволяє уникнути підтримки двох повністю окремих баз коду.

Під час внесення змін ви переважно працюєте над реалізацією асинхронного коду в neomodel/async_ а потім запустіть наданий скрипт транспіляції, щоб згенерувати варіант синхронізації. Ви також можете покластися на перехоплювачі перед комітом, щоб автоматизувати цей крок і забезпечити синхронізацію обох версій. У багатьох випадках вашу бізнес-логіку потрібно записати лише один раз на асинхронному рівні.

Деяка функціональність може бути призначена лише для асинхронного використання або лише для синхронізації, і neomodel надає шаблон утиліти (натхненний офіційним драйвером Neo4j) для розділення цих шляхів коду. Це дозволяє вам визначити поведінку, яка відрізняється між двома режимами, зберігаючи при цьому загальну узгодженість поверхні API. Тестові модулі, такі як ті, що охоплюють Match API, демонструють, як транспілюється асинхронний код і як поводиться результуючий синхронізований код.

Синглтони бази даних та AsyncDatabase

У неомоделі 6, Database() та AsyncDatabase() Класи реалізовані як справжні одиночні об'єкти (синглтони), щоб уточнити, як обробляються глобальні операції. Замість розпорошення окремих допоміжних функцій, neomodel тепер групує операції всієї бази даних в ці екземпляри-синглтони, що робить API більш видимим та узгодженим.

Кілька застарілих функцій було перенесено до Database() клас та видалено з глобального простору імен. Приклади включають в себе change_neo4j_password, clear_neo4j_database, drop_constraints, drop_indexes, remove_all_labels, install_labels та install_all_labelsАсинхронні аналоги доступні з AsyncDatabase() синглтон, зазвичай позначений як adb в асинхронному контексті.

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

Крім того, у версії 6.0 було представлено merge_by параметр для пакетних операцій, що забезпечує більше контролю над об'єднанням вузлів та зв'язків. Ви можете налаштувати, які мітки та ключі властивостей визначають унікальність для пакетних об'єднань, що критично важливо під час обробки великих обсягів даних або завдань синхронізації.

Інтеграція з Django та використання в реальному світі

Neomodel чітко інтегрується з Django через django_neomodel пакет, що дозволяє вам розглядати ваші графові моделі як частину проекту Django. Завдяки цій інтеграції конфігурація зазвичай знаходиться в settings.py, а ваші класи вузлів та зв'язків співіснують з рештою вашої екосистеми Django, включаючи додатки, проміжне програмне забезпечення та представлення.

Конкретним прикладом є багатоетапний навчальний посібник з Django, який використовує neomodel для дослідження та пошуку в графовій базі даних у стилі Paradise Papers. У перших частинах ви налаштуєте проєкт Django та інтегруєте neomodel; у наступних частинах ви створите fetch_api додаток, визначити моделі, що відображають сутності, зв'язки та властивості в графі, а потім поступово створювати утиліти та представлення поверх них.

У такому проєкті ви можете використовувати моделі neomodel безпосередньо всередині представлень Django, серіалізаторів або допоміжних модулів. Поширений підхід полягає у створенні utils.py файл, де ви визначаєте зручні функції, що викликають API запитів. Наприклад, ви можете реалізувати count_nodes, fetch_nodes та fetch_node_details помічники, які динамічно завантажують фільтри, параметри пагінації та імена моделей.

Деякі дані, такі як списки країн, юрисдикцій або джерел даних, можуть бути ресурсоємними для багаторазового запитування, тому ви можете попередньо обчислити їх за допомогою необробленого Cypher та зберегти як константи. A constants.py Модуль може виконати ці запити Cypher один раз, отримати відсортовані списки, наприклад COUNTRIES, JURISDICTIONS та DATASOURCE, та зробіть їх легко імпортованими у ваш застосунок Django.

Щоб забезпечити готовність цих констант під час запуску програми, ви можете підключитися до конфігурації програми Django, визначивши ready() метод в fetch_api/app.py. Усередині цього методу ви імпортуєте constants.py, що запускає початкові запити Cypher та заповнює відповідні списки. Таким чином, наступні запити можуть просто зчитувати дані з уже підготовлених структур даних.

Raw Cypher проти OGM для складних запитів

Хоча OGM від neomodel ідеально підходить для щоденного CRUD та обходу зв'язків, існують сценарії, в яких вручну написані запити Cypher є ефективнішими. Глибоко вкладені обходи, запити другого ступеня або багатострибкові запити, а також складні агрегації іноді можна виразити чіткіше та з кращою продуктивністю як необроблений Cypher, ніж як ланцюги OGM.

Типовим прикладом є пошук акторів, які знімалися в будь-якому фільмі разом з певним актором, наприклад, визначення всіх людей, які працювали з Томом Генксом. Як запит Cypher, це може бути досить прямим: ви зіставляєте актора, переходите до фільмів, у яких він знімався, а потім переходите до інших акторів у цих фільмах, застосовуючи фільтри та агрегації за потреби. Результатом є лаконічний, оптимізований графічний шаблон.

Реплікація тієї ж поведінки виключно за допомогою зручних методів OGM може вимагати процесу в стилі O(n²), перебираючи фільми та пов'язані з ними актори на рівні Python. Це і менш елегантно, і менш ефективно, ніж дозволити Neo4j виконувати важку роботу в одному операторі Cypher. Це ілюструє, що OGM не є панацеєю від усіх шаблонів доступу до графів.

Більше того, коли ви покладаєтеся на операції OGM для глибокого обходу, форма повернутих даних може стати досить складною. Згенерований Cypher часто включатиме початковий вузол, проміжні зв'язки, сусідні вузли та їхні зв'язки. Це може бути корисним, коли вам потрібен насичений контекст, але може бути надмірним, коли вам потрібні лише конкретні агреговані результати або підмножина властивостей.

У ситуаціях, коли продуктивність та чіткість мають першочергове значення, використання cypher_query Безпосереднє виконання ручної роботи Cypher може бути кращим варіантом. Neomodel навмисно використовує цей аварійний механізм: ви можете поєднувати високорівневі взаємодії OGM з низькорівневими Cypher в одному проєкті, вибираючи правильний інструмент для кожного конкретного запиту, зберігаючи при цьому моделі як єдине джерело достовірної інформації для вашої схеми.

Neomodel у Neo4j Labs та управління проектами

Перехід Neomodel до програми Neo4j Labs формалізував його статус як активно підтримуваного, спільнотного проєкту з чіткими очікуваннями щодо якості. Neo4j Labs слугує домівкою для експериментальних та просунутих проектів, які мають реальний успіх, але не є частиною основного продукту. Багато відомих інструментів, таких як компоненти для обробки графових даних, бібліотека GraphQL, ядро ​​APOC та потокові інтеграції, мають коріння в цій програмі.

Належність до Neo4j Labs означає, що neomodel дотримується базових стандартів тестування, перевірок безпеки та автоматизованих інструментів, таких як конвеєри CI/CD. Команда підтримки проводить інтеграційні тести з широкою матрицею версій Python та Neo4j, забезпечуючи сумісність із виходом нових релізів. Це одна з причин, чому neomodel може стверджувати про повну підтримку всіх підтримуваних наразі версій Python та Neo4j, як Community, так і Enterprise.

Проєкт залишається повністю відкритим та орієнтованим на спільноту, а GitHub слугує основним центром для вирішення проблем, обговорень та внесків. Журнал проблем знову активно курується, старі елементи сортуються та узагальнюються за можливості, тоді як область обговорень відкрита для всіх і використовується для оголошень та обговорень дизайну. Принаймні один співробітник Neo4j виконує обов'язки супроводжуючого, використовуючи польовий досвід у проекті.

Реальні виробничі розгортання, такі як OpenStudyBuilder від Novo Nordisk, відіграють важливу роль у формуванні дорожньої карти neomodel. Ці масштабні, реальні програми містять конкретні вимоги та відгуки, які перетворюються на нові функції та покращення, що надаються спільноті. Цей корисний цикл показує, як використання в корпоративному середовищі та розробка з відкритим кодом можуть взаємно підсилювати одне одного.

Завдяки моделюванню на Python, потужному вирівнюванню Neo4j, API асинхронізації та синхронізації, а також активній еволюції, що підтримується Lab, neomodel пропонує переконливий спосіб роботи з графіками з Python як у невеликих проектах, так і у вимогливих виробничих системах. Використовуючи його продумано — спираючись на OGM для чіткого моделювання предметної області та типових взаємодій графів, а також звертаючись до необробленого Cypher, коли цього вимагають складні шаблони або продуктивність, — він може значно спростити процес проектування, запитування та підтримки графових застосунків.