Неблокирующие проблемы ORM


9

Я задал вопрос о SO и обнаружил, что для моей любимой веб-платформы нет неблокирующих ORM. Под неблокированием я подразумеваю ORM с поддержкой обратного вызова для асинхронного поиска. ORM должен быть снабжен обратным вызовом или чем-то подобным для выполнения при получении данных.

Я хочу создать его, но у меня есть несколько вопросов, которые мешают мне начать разработку:

  • Какие проблемы могут возникнуть при разработке ORM?
  • Значительно ли поддерживает неблокируемый поиск сложность ORM?
  • Почему вокруг так мало неблокирующих ОРМ?

Обновление: похоже, я должен улучшить свой вопрос. У нас есть решения, которые уже позволяют нам получать данные неблокирующим способом, и я считаю, что большинство компаний, использующих такие решения, используют сырой SQL. Мы хотим создать более общее решение, которое мы можем использовать в будущих проектах. С какими трудностями мы можем столкнуться?

Обновление 2: Предпочитаемый язык - Python, но меня интересуют принципы. Этот вопрос на самом деле для меня, так как я буду смотреть на платформы, которые уже имеют неблокирующую ORM.


2
Что такое «неблокирующая ORM»? Как вы можете отобразить данные до их получения?
Роберт Харви

6
@RobertHarvey: асинхронный поиск звучит довольно неплохо. ORM будет снабжен обратным вызовом или чем-то подобным для «активации», когда данные будут получены. В противном случае ваш ORM должен быть разделен на отдельный поток, чтобы гарантировать отзывчивость пользовательского интерфейса.
Марьян Венема

@MarjanVenema, да, я хочу ORM с поддержкой обратного вызова.
Николай Фоминых

1
Так почему бы просто не использовать асинхронные обратные вызовы с вашим любимым синхронным ORM? stackoverflow.com/q/1239035
Роберт Харви

@RobertHarvey, потому что синхронный ORM блокирует асинхронный сервер.
Николай Фоминых

Ответы:


2

Какие проблемы могут возникнуть при разработке ORM?

Вам нужно будет обратиться к перечню проблем, необходимых для преодоления несоответствия реляционного импеданса объектов , а также к особенностям SQL, предоставляемым каждым поставщиком СУБД. Чем более продвинуты ваши требования, тем хуже будут ваши проблемы в этом отделе: например, SQL, который вы генерируете для реализации подкачки результатов, будет довольно сильно отличаться для Oracle, SQL Server и mysql. К счастью, это не отличается между блокирующими и неблокирующими реализациями ORM, поэтому, если есть ORM с открытым исходным кодом для Python, вы сможете использовать его для решения почти всех этих проблем.

Значительно ли поддерживает неблокируемый поиск сложность ORM?

Самая большая проблема, с которой вы столкнетесь, заключается в том, что библиотека соединений для доступа к самой СУБД будет блокироваться. Это еще одно отличие, которое вы должны устранить. Управление потоками, невидимыми для ваших пользователей, станет дополнительной проблемой для вас. Кроме того, загрузка зависимостей по требованию была бы проблемой, потому что пользователи воспринимают эту операцию как синхронную: в конце концов, они обычно не ожидают уведомления о том, когда можно получить доступ к свойству коллекции своего объекта.

Почему вокруг так мало неблокирующих ОРМ?

Я могу только размышлять об этом последнем пункте, но я думаю, что это связано с низким спросом на такие платформы: поскольку вы можете частично моделировать неблокирующую ORM, добавляя другой уровень потоков в код приложения по мере необходимости, и сохраняя регулярную блокировку В любом случае, разработка специализированной структуры для этого представляется неоптимальной.


Не уверен, что ответ на этот вопрос может быть лучше. Спасибо.
Николай Фоминых

6

Вы не сказали, какой язык используете, поэтому я порекомендую Node.js и ORM для него: Node ORM , все в узле асинхронно, это ничем не отличается.


Вопрос обновлен.
Николай Фоминых
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.