9

I asked a question on SO, and found that there are no non-blocking ORMs for my favorite web framework. By non-blocking I mean an ORM with callback support for asynchronous retrieval. The ORM would be supplied with a callback or some such to execute when data has been received.

I want to create one, but I have some questions that blocking me from starting development:

  • What issues might be encountered when developing ORM?
  • Does supporting non-blocking retrieval dramatically increase the complexity of an ORM?
  • Why are there so few non-blocking ORMs around?

Update: It looks like I have to improve my question. We have solutions that already allow us to receive data in non-blocking way, and I believe that most companies that use such solutions use raw SQL. We want to create a more generic solution that we can reuse in future projects. What difficulties might we encounter?

Update 2: Preferred language is python, but I'm interested in principles. This question is actually for me, as I will look at platforms which already have non-blocking ORM.

Community
  • 1
Nikolay Fominyh
  • 1,038
  • 9
  • 17
  • 2
    What is a "Non-blocking ORM?" How can you display the data *before* you receive it? – Robert Harvey Jun 22 '12 at 01:32
  • 6
    @RobertHarvey: asynchronous retrieval sounds pretty good actually. The ORM would be supplied with a callback or some such to "activate" when data has been received. Otherwise your ORM needs to be split of in a separate thread to guarantee UI responsiveness. – Marjan Venema Jun 22 '12 at 07:05
  • @MarjanVenema, yes, I want ORM with callback support. – Nikolay Fominyh Jun 22 '12 at 07:21
  • 1
    So why not just use asynchronous callbacks with your favorite synchronous ORM? http://stackoverflow.com/q/1239035 – Robert Harvey Jun 23 '12 at 02:40
  • @RobertHarvey, because synchronous ORM blocks asynchronous server. – Nikolay Fominyh Jun 24 '12 at 06:51
  • I know this isn't a proper answer but just wanted to mention MySQL's features for low-importance stuff that kinda mirrors some properties of asynchronous calls. http://stackoverflow.com/questions/3234972/advantages-of-update-low-priority-and-insert-delayed-into – James Jun 24 '12 at 07:12
  • @James: Actually, all of the major SQL DBMS products have fully asynchronous interfaces built-in. They just aren't ORM. – RBarryYoung Jun 24 '12 at 13:42

2 Answers2

6

You didn't say which language you're using so I'm going to recommend Node.js, and an ORM for it: Node ORM, everything in node is async, this is no different.

gbjbaanb
  • 48,354
  • 6
  • 102
  • 172
2

What issues might be encountered when developing ORM?

You'll need to address the laundry list of issues required to bridge the Object Relational Impedance Mismatch, as well as dealing with idiosyncrasies of SQL provided by each RDBMS vendor. The more advanced your requirements get, the worse your troubles would be in this department: for example, SQL that you generate to implement results paging will differ rather dramatically between Oracle, SQL Server, and mysql. Fortunately, this is not different between blocking and non-blocking ORM implementations, so if there is an open-source ORM for Python, you would be able to heavily borrow from it to address nearly all these issues.

Does supporting non-blocking retrieval dramatically increase the complexity of an ORM?

The biggest issue that you are going to face is that the connection library for accessing the RDBMS itself would be blocking. This is another difference that you must address. Managing the threads invisible to your users will be the additional challenge for you. In addition, loading of dependencies on demand would be a challenge, because the operation is perceived as synchronous by the users of your framework: after all, they do not normally expect a notification on when it's OK to access a collection property of their object.

Why are there so few non-blocking ORMs around?

I can only speculate on this last point, but I think it has to do with low demand for such frameworks: since you can partially simulate non-blocking ORM by adding another level of threading to your application code as needed, and keep the regular blocking kind everywhere else, developing a specialized framework for it would seem suboptimal.

Sergey Kalinichenko
  • 17,393
  • 4
  • 57
  • 73