Neomodel Python OGM: Дълбоко потапяне в Neo4j моделирането

Начало » Питон » Neomodel Python OGM: Дълбоко потапяне в Neo4j моделирането

Neomodel е Python Object-Graph Mapper (OGM), проектиран да направи работата с Neo4j толкова естествена, колкото писането на обикновен Python код. Вместо ръчно да създавате Cypher заявки през цялото време, вие описвате графичния си домейн с класове, полета и взаимоотношения и оставяте neomodel да обработва съпоставянето между Python обекти и Neo4j възли и взаимоотношения. Той е изграден върху официалния Neo4j Python драйвер, само с тънък слой абстракция, така че получавате удобство на високо ниво, без да жертвате голяма производителност.

Като част от екосистемата на Neo4j Labs, neomodel се поддържа активно, напълно поддържа съвременни версии на Python и Neo4j и предлага както синхронни, така и асинхронни API. Той предлага познати, подобни на Django дефиниции на модели, богат API за заявки, прилагане на схема чрез кардиналност, вградени транзакции и тясна интеграция с Django чрез django_neomodelВ същото време, той остава близо до метала: винаги можете да преминете към суров Cypher, когато производителността или сложността на заявките го изискват.

Какво е неомодел и защо е важен

Neomodel е инструмент за картографиране на графове на обекти за графовата база данни 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 и конфигурация

Съвременните издания на neomodel следват семантично версиониране (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, конфигурацията се обработва чрез модерен, анотиран по тип клас данни с валидиране по време на изпълнение и поддръжка на променливи на средата. Вместо разпръснати ad-hoc настройки, конфигурационните полета се валидират при актуализация, включително проверки на типа и логически ограничения. Променливите на средата могат да се използват за лесно презаписване на конфигурацията, което е чудесно за контейнеризирани внедрявания и облачни среди.

Версия 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 базов клас. Класовете, производни от този тип, могат да съдържат „ad-hoc“ свойства, които не са били изрично дефинирани в модела. Това е особено удобно, когато вашата графична схема се развива често или когато трябва да добавяте допълнителни атрибути, без да рефакторирате модела всеки път.

Правилата за кардиналност налагат броя на допустимите връзки между възлите и вече са подкрепени от по-строги проверки в neomodel 6. Меките проверки за кардиналност са налични за всички кардиналности на взаимоотношенията, а стриктната проверка е активирана по подразбиране. Ако вашите данни нарушават конфигурираните правила за взаимоотношения, neomodel ще покаже този проблем, вместо тихо да позволи на непоследователната структура да се запази.

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

След като дефинирате или актуализирате моделите си, трябва да приложите съответните ограничения и индекси към базата данни Neo4j. Neomodel се доставя със скрипт, наречен neomodel_install_labels който сканира вашите модели и създава или актуализира необходимите индекси и ограничения. След като промените схемата си, трябва да изпълните този скрипт и да прегледате отчетения брой обработени класове, за да потвърдите, че всичко е синхронизирано.

Ако някога се наложи да премахнете ограничения и индекси, управлявани от neomodel, има допълнителна команда, наречена neomodel_remove_labels. Този скрипт автоматично премахва всички съществуващи ограничения и индекси, които neomodel е инсталирал преди това. Той също така отпечатва какво е било премахнато, за да видите ясно въздействието на операцията.

И двете команди за управление на схеми поддържат a --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 системи обработват постоянството (persistence).

Актуализирането на възлите следва същия модел: извличане на екземпляр, присвояване на нови стойности на неговите атрибути и запазването му отново. Neomodel се грижи за генерирането на правилния Cypher, за да модифицира само променените свойства на съществуващия възел. Този подход поддържа кода ви ясен и не включва детайлите на операциите по актуализиране в бизнес логиката ви.

Изтриването на възел също е директно: след като имате екземпляр, извиквате неговия delete() метод. Това премахва възела и, в зависимост от конфигурацията на вашата връзка и ограниченията на базата данни, може също да премахне прикачени връзки. За по-разширено поведение или регистриране могат да бъдат дефинирани куки преди и след изтриване.

Връзките между възлите се управляват чрез полета за връзки и удобни методи, като например connect(). След като имате два възела, можете да извикате нещо подобно actor.movies.connect(movie) за да се създаде подходящ екземпляр на връзка в графиката. Свойствата на връзката могат да бъдат моделирани чрез StructuredRel-базирани класове, което ви дава място за съхраняване на атрибути и по ръбовете.

По-сложни обходи на графи могат да бъдат постигнати чрез следване на атрибути на взаимоотношения или комбиниране на филтри за заявки в различни взаимоотношения. Например, можете да започнете от Entity набор от възли, филтриране по някакво свойство и след това преминаване към свързани възли, за да се филтрира и по техните атрибути. Това постепенно изгражда Cypher заявка „под капака“, която neomodel изпълнява от ваше име.

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

Neomodel включва асинхронна поддръжка, изградена върху асинхронните възможности на официалния Neo4j Python драйвер. Това означава, че можете да интегрирате Neo4j операции в съвременни асинхронни Python рамки и услуги, като се възползвате максимално от едновременността за работни натоварвания, които включват много I/O операции.

Тестването на производителността с инструменти като Locust показа, че async neomodel, когато се използва едновременно, превъзхожда както серийните заявки, така и едновременно изпълняваните синхронни извиквания на neomodel. Тъй като много графични операции включват мрежови входно-изходни операции и чакане на отговори от базата данни, позволяването на цикъла на събития да обработва множество заявки едновременно води до по-добра пропускателна способност и използване на ресурсите.

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

Когато допринасяте, работите предимно върху асинхронната имплементация под neomodel/async_ и след това изпълнете предоставения скрипт за транспилация, за да генерирате варианта за синхронизация. Можете също така да разчитате на кукички преди записване (pre-commit hooks), за да автоматизирате тази стъпка и да гарантирате, че двете версии остават синхронизирани. В много случаи вашата бизнес логика трябва да бъде написана само веднъж в асинхронния слой.

Някои функции може да са предназначени само за асинхронно или само за синхронизирано използване, а 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 въведе a 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 подравняване, async и sync API и активната еволюция, подкрепена от Lab, neomodel предлага завладяващ начин за работа с графики от Python както в малки проекти, така и в взискателни производствени системи. Използван обмислено – като се разчита на OGM за ясно моделиране на домейни и типични графови взаимодействия, и се посяга към суровия Cypher, когато сложни модели или производителност го изискват – той може значително да опрости начина, по който проектирате, заявявате и поддържате графово-базирани приложения.