New Opa S4 Release Puts Forward New 'ORM' For MongoDB 29
phy_si_kal writes "The new, open source, Opa web programming language just hit version 0.9.0 'S4,' six months after its last major release. Apart from a new syntax more similar to JavaScript, the new release focuses on mongoDB integration. Opa now features something similar to object-relational mapping (ORM) except that mongoDB is a non-relational, document-oriented database and Opa a functional, non-object-oriented language. The new functionality makes the NoSQL database even easier to use, as all language-database calls are automated. The mapping of functional datastructures to documents could even be much better than current ORM approaches and solve the object-relational impedance mismatch."
Mongo stay with Sherrif Bart (Score:4, Funny)
It has a very unfortunate name. (Score:1)
In a number of languages, especially European ones, "mongo" is a slang word referring to mental retardation. This is due to "mongoloid" being a common term for Down syndrome in the past.
When the hype was first building up around NoSQL databases a few years ago, some German and Dutch co-workers of mine burst out laughing in a meeting when somebody else mentioned MongoDB. To them, the database was basically named "RetardDB".
When programming tools and databases meet.. (Score:3)
...interesting things happen. I have always felt that the object-relational impedance mismatch was a mental block holding back the redevelopment of something we actually used to have (integrated programming tool/database platforms - look at things like D3, Cache/MUMPS for example).
Now, we know we can separate the representation of data in a database from the data itself, but the two can look identical, with a middleware as the go-between between the programming tools and the database. Or they can co-habit.
It doesn't matter what you call it, but I like it.
My dream environment = perfect representation of data in flexible/dynamic objects in a programming language, disconnected or connected to databases with nearly identical, flexible and dynamic data model representation, with a powerful query language (SQL-like), the scalability of the new generation of shared-nothing architectures, simple connectivity options (simple sockets all the way up to REST) and the reliability of a relational database's ACID properties.
It feels so close!
Re: (Score:2)
The O/R impedance mismatch may be a mental block but not the O/SQL one.
This complicates as the DBMS vendors are really good at improving SQL queries that doesn't necessarily fit the object model or the mapping layer.
For non trivial projects you end up applying the O/R mapping to replace the trivial SQL sencences, and the "raw" SQL (or even stored procedures) for the contrived or performance critical cases... which in the long term is a PITA.
Re: (Score:2)
My dream environment = perfect representation of data in flexible/dynamic objects in a programming language, disconnected or connected to databases with nearly identical, flexible and dynamic data model representation, with a powerful query language (SQL-like), the scalability of the new generation of shared-nothing architectures, simple connectivity options (simple sockets all the way up to REST) and the reliability of a relational database's ACID properties.
Amen. Your storage layer shouldn't dictate your usage patterns; quite the opposite, actually. But domain entities seldom conform to a single usage pattern -- there's one set of them in OLTP, and OLAP, and another for use in realtime incides, etc. Having to have myriad representations of an object just to accommodate different persistence patterns is wasteful.
Re: (Score:2)
My dream environment = perfect representation of data in flexible/dynamic objects in a programming language, disconnected or connected to databases with nearly identical, flexible and dynamic data model representation, with a powerful query language (SQL-like), the scalability of the new generation of shared-nothing architectures, simple connectivity options (simple sockets all the way up to REST) and the reliability of a relational database's ACID properties.
It feels so close!
It feels close because it happened a while ago and you didn't realise it. Introducing: The Abstraction Layer!
This revolution in software design allows one to incorporate OR decouple the capabilities of one system from or to another! Finally! We can all spout gibberish about the endless possibilities! It's Abstraction, all the way from indirection at the CPU op-code level all the way up to $EVERYTHING, and provides the reliability of whatever back-end you decide to use. As a bonus, it supports ORM, CO
Re: (Score:2)
It's important that we don't forget the past, but also that we open our minds to new possibilities in the future. I agree with your sentiment- I don't like "the next shiny widget which really just reinvents the wheel" kind of thinking either, and I certainly won't defend it.
That said, I think things like Opa represent a nice take on abstraction in that the mismatch between the technologies that are being interfaced is conceptually much lower (data structures <-> data storage with less in the way), so
Re: (Score:2)
Now, we know we can separate the representation of data in a database from the data itself, but the two can look identical, with a middleware as the go-between between the programming tools and the database. Or they can co-habit.
It doesn't matter what you call it, but I like it.
Hows about "create view" ?
My dream environment = perfect representation of data in flexible/dynamic objects in a programming language, disconnected or connected to databases with nearly identical, flexible and dynamic data model representation, with a powerful query language (SQL-like), the scalability of the new generation of shared-nothing architectures, simple connectivity options (simple sockets all the way up to REST) and the reliability of a relational database's ACID properties.
ACID + disconnected databases = oxymoron
Thinking you can treat online and disconnected databases the same since they are both "databases" = dellusional.
dynamic data model = see self modifying code
http based Implementations of the idea of REST suck for anything but trivial CRUD.
Shared nothing + crappy schema = so much for scalability.
Until singularity time schema design is and shall remain more important than selection or use of underlying technology.
Scalable, consistant/reliable
Re: (Score:2)
Hows about "create view" ?
We're not talking about views that live in the database. You don't "create view" in C++, but in the end, aren't objects just structured data + behavior? Objects can act as a bridge to data which gives it meaning through structure, and function. Map data structure (in my programming language) direct to data storage (in my database), with little in between, even if my data structure is on one physical machine, and my storage is on another.
ACID + disconnected databases = oxymoron
It depends on how you define ACID. You can have an ACID transaction
Re: (Score:2)
That's the crux of the problem. You see the programming language as having the actual structure, and that dusty databasey thingie over there as having some sort of optimized-for-storage representation of the data. In reality, that database has a much richer notion of your data than your program does, and your prog
Re: (Score:2)
To take CREATE VIEW one step further, I was dreaming about something like this - given guaranteed always on network connectivity with plentiful bandwidth (I know, unrealistic, but just follow me for a moment), imagine that the view actually existed in the software layer separated by the network from the database. That the view could exist on the client, but the data on the server at all times. This is what I mean by disconnected - not so much that the data has to live on the client, but that the view is n
Too bad. (Score:1)
what the which? (Score:2)
acronym overload, somebody call AAAAAAAAAAA!
Just because you have a hammer.. (Score:3)
This is interesting.
What strikes me though is the stuff about ORM and how this isnt ORM, like its some new fangled way to use a database that nobody did before.
Here's the thing. You can do this in any language. yes this opa language has some simple syntactic sugar to make it super easy to use a database (as long as its a NoSQL one like mongo). But you can access a database without an ORM layer in any other language too.
Thing is, with OO languages, people assume you have to do everything with objects. Its there, I gotta use it! Right? I have this lovely hammer and it smashes real good, therefore I will smash screws with it! And I will smash apart wood sheet into sections! Never mind that screwdriver and saw over in the corner.. I have hammer!
So somebody makes a non-oo language that accesses a database with simple records and everybody thinks its a new and novel thing..
(don't get me wrong, the language looks interesting, I just think its funny how people look at things and run off half cocked without thinking first)
Re: (Score:1)
Just for the record: we (i.e. creators of Opa) don't claim we (re) invented the wheel. But we do think that what we provide is quite cool. And what that is?
Re: (Score:2)
oh, dont get me wrong, I didn't think you guys did claim any such thing. :) opa looks pretty interesting (though I would like OO ability as an option).
I've been anti ORM for some time now.
Re: (Score:1)
Turns out, I've been telling for years that I don't like them, as they add yet another layer in the technology soup.
But the duo Opa + MongoDB is way different. It's a very thin layer of technology at runtime to build web applications. And I guess neither are very easy to implement.
There may have been similar solutions at the mainframe era, but the advantages of those two is that they are built on the "modern" standards and in the end allow to
BFD, WTF, make it stop (Score:2)
I call BS (Score:2)
You can't call it an ORM solution if the backend isn't a relational database. Where are the relations? There aren't any. There's just documents. Not an ORM. This is not 'Nam, there are rules.
Moreover, this has nothing to do with the actual problem. The reason MongoDB et. al. are gaining steam is precisely because there are these "web scale" morons running around ignoring real problems like data validity in favor of starry-eyed dreamland problems like scalability. You can write nice happy OO-like bindings to
Re: (Score:2)
Integration with any database encounters the problem of connecting the programmer-centric paradigms (often objects) to the data-centric backend organization, which in an RDBMS is a relation. This problem is solved by ORM. MongoDB users encounter the same ultimate problem, but their backend simply doesn't use relations. It is inaccurate but not wholly inappropriate to say that MongoDB's integration can be eased by an ORM-like solution. The term is abused for the sake of communication.
MongoDB (and other NoSQL
Re: (Score:1)
You can't call it an ORM solution if the backend isn't a relational database. [...]
There's a reason why ORM in the title is between quotes :). What we did is took a database that, as Sarten-X pointed out, "is not intended for instantaneous and atomic validity". We then used the type-safety of the host language to ensure that schema-like constraints are respected by the application. We also made sure that we have a good mapping between the host language (Opa) data-types (also those defined by the user) and the DB representation, therefore allowing easy persistence of any program data. Opa
MongoDB, SchmongoDB, Opa's the real story here (Score:2)
As someone who has downloaded this some time back and messed with it a bit, I do have to say it's kind of slick.
http://opalang.org/ [opalang.org]
I had a few complaints about it early on, but it's evolving, though. Might be worth revisiting.
Re: (Score:1)
As someone who has downloaded this some time back and messed with it a bit, I do have to say it's kind of slick.
Glad to hear that :).
I had a few complaints about it early on, but it's evolving, though. Might be worth revisiting.
You should absolutely do that. We've come a long way since the beginning. And we're not done yet!
Re: (Score:1)