Slashdot Mirror

← Back to Stories (view on slashdot.org)

New Opa S4 Release Puts Forward New 'ORM' For MongoDB

Posted by Soulskill on from the new-and-shiny dept.

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."

29 comments

  1. Mongo stay with Sherrif Bart by NoNonAlphaCharsHere · · Score: 3, Funny

    Sherrif Bart first man ever to whip Mongo. Mongo impressed.

  2. Is it still web scale? by Anonymous Coward · · Score: 0, Funny

    http://www.youtube.com/watch?v=b2F-DItXtZs

    1. Re:Is it still web scale? by Anonymous Coward · · Score: 0

      Yeah saw this in another posting a few days ago and just about herniated myself I was laughing so hard. And it was exactly the first thing I thought of when I saw 'mongodb'. And I think it will always be the first thing I think of when I hear or see 'mongodb'. And it is so right on the mark that it makes it even funnier.

  3. When programming tools and databases meet.. by SixDimensionalArray · · Score: 2

    ...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!

    1. Re:When programming tools and databases meet.. by DiegoBravo · · Score: 1

      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.

    2. Re:When programming tools and databases meet.. by RareButSeriousSideEf · · Score: 1

      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.

      --
      Pi Ran Out
    3. Re:When programming tools and databases meet.. by VortexCortex · · Score: 1

      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, COBRA, RPC, REST, ACID, LSD, BS, BSD, FLOSS, RINSE, RePEAT and your business logic isn't tied to your damn database choices!

    4. Re:When programming tools and databases meet.. by SixDimensionalArray · · Score: 1

      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 the necessary abstraction is less complex. It's nice to see it working for them. Sure there are some glaring oddities, like why call it ORM if there are no objects - but I think it's the inspiration, not the implementation that matters.

      If I spent all day writing C or assembly operating in my own little world on my own timetable, I could build anything I want, interface it however I wanted to, abstract it however I felt like. I could do that even in higher-level languages. But "application developers", operating at high levels of abstraction, would be quite pleased with any improvements in the underlying abstractions that makes their code/systems faster, less complex, and/or conceptually easier to understand. That is probably even true of low-level programmers.

      This kind of reduction in complexity seems to be happening a lot lately - look at Windows 8 - Microsoft is doing more work in C++ and lower levels and seems to be moving more abstract concepts to a lower level in the stack, and also encouraging use of more concrete programming concepts. From the outside it looks like the moves they are making are adding a lot more abstractions and complexity, but I think that's partially because they are trying to maintain previous ways of doing things, while advancing the core.

      In my opinion, the more we can reduce abstraction over the long run, the better.

    5. Re:When programming tools and databases meet.. by WaffleMonster · · Score: 1

      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 and easy to design... pick any two.

    6. Re:When programming tools and databases meet.. by SixDimensionalArray · · Score: 1

      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 happen in a database on your phone, which then syncs to a database on your server with an ACID transaction. Other than a time delay in the transaction, what is the difference? I mean disconnected more in the sense like, in this case, a data structure is really just a direct map/representation of a model in a database. In that kind of scenario, when the connection between database and application is severed, yes, you don't get ANY transactions, but maybe you could work with disconnected data and sync up later. Furthermore, ACID and DISTRIBUTED data works - see any massively parallel relational database implementation like Teradata, SQL Server Parallel Datawarehouse, MySQL Cluster, etc.

      Thinking you can treat online and disconnected databases the same since they are both "databases" = dellusional.

      Well, of course they are not the SVOT (single version of the truth) if there are two copies of one piece of data. However, if the data I need is in my disconnected database, and it synchronizes with an online database as soon as one is available, it's hard but not dellusional. Plenty of apps try to use offline storage as a cache when disconnected from the main data store, for example.

      dynamic data model = see self modifying code

      Yup, so now give me lots of implementations and make them easy to use.

      http based Implementations of the idea of REST suck for anything but trivial CRUD.

      That's probably true in some cases, but I wouldn't want to throw the baby out with the bathwater - if you have control of the REST stack, you can expose anything you want from your application code or your database, as long as you follow REST principles.

      Shared nothing + crappy schema = so much for scalability.

      That's not necessarily true if your code is the interface to your database and if your code enforces the necessary constraints so that your database can play dumb. But generally, yeah, if you don't structure and define rules for your data (schema), then sure you will have problems

      Until singularity time schema design is and shall remain more important than selection or use of underlying technology.

      Hmm, I don't know about you, but the singularity happening is cool by me. I mean, I'm not saying it will or it is... but it would be cool.

      Scalable, consistant/reliable and easy to design... pick any two.

      That's why it's a dream... but all progress depends on the unreasonable man!

    7. Re:When programming tools and databases meet.. by fusiongyro · · Score: 1

      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.

      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 program has an optimized-for-this-calculation representation.

      The proof WaffleMonster submits is the CREATE VIEW statement. This little feature isn't a way of making your SELECTs shorter. It's a way of allowing your applications to restructure the data being stored without introducing copies. It's a way to ensure that when the database is refined (i.e. storing more in more complex ways) the applications you already have don't need to be rewritten to participate.

      It depends on how you define ACID

      Not really. Every distributed database forgoes some aspect of ACID compliance. Take my shitty iTunes Match service. Just today, I had to delete 28,000 copies of a playlist from iTunes. Why? Because iTunes Match doesn't know who to believe when two devices disagree about a playlist having been made, so it defaults to resolving the conflict by creating a playlist rather than deleting. In a distributed scenario, you are going to have to decide how to handle conflicting versions of the truth. MySQL cluster is marketed as if you don't need to do that, but as someone who has run MySQL with replication, I can tell you, it's extremely fragile. The PostgreSQL version is much harder to set up. Why? Because there are hard questions there that you have to be able to answer, but if you are essentially a front-end engineer who's really excited about Node.js, you have no fucking idea what a hard problem is.

      The absolute irony about this whole situation is that all this effort is being made to enable distributed data storage why? So we can have one domain with all our data on it: Facebook, Twitter or whatever. Wouldn't it be neat if, instead of having these massive centralized systems we had some kind of distributed way of hooking computers together?

      Plenty of apps try to use offline storage as a cache when disconnected from the main data store, for example.

      Yes, and how many of them get it right? Using a local store as a cache is explicitly giving up on ACID compliance: you have to be able to anticipate the situation where your changes can't be applied to the server, and what to do if that happens. This is an application-level problem that can't be swallowed by the database. In some apps, the server will always be right, in some apps the client will always be right, but in most apps, it will be a nasty ad-hoc combination of the two that will demand mental effort to reconcile.

      That's not necessarily true if your code is the interface to your database and if your code enforces the necessary constraints so that your database can play dumb.

      If you're doing this, you're wasting your database and you're lying to yourself. You're lying to yourself because you think you can shoulder the burden of writing integrity into your application. You're also lying to yourself if you think you can manage concurrency correctly, and you're lying to yourself if you think that your application or library is the only one that's going to access your data and can be the gatekeeper. If any of these things seems reasonable to you, come back here in a decade and let's talk about how it worked out for you.

      Relational databases, the good ones anyway, have 30-40 years of debugging and optimization poured into them. If you want to take a year and do your little "database" proj

    8. Re:When programming tools and databases meet.. by Anonymous Coward · · Score: 0

      ...This is the opposite of what's going on with NoSQL: a rejection of what came before..., complete lack of acknowledgement that they are reimplementing the very network and hierarchical databases that preceded relational databases, all of the emphasis is on performance and almost none of it is on reliability, expressiveness or any sort of mathematical attribute that data might have. No knowledge of what came before and what mistakes they might be repeating.

      The sad thing is that one read through a good database textbook would result in most of this nonsense disappearing overnight.

      I'll admit that I have been tempted to play with MongoDB - but with the understanding that it's basically a gigantic hash map that might lose a record here or there. I haven't found any really good uses for it because of those parameters, though.

    9. Re:When programming tools and databases meet.. by SixDimensionalArray · · Score: 1

      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 not database-resident.

      Imagine running a CREATE VIEW statement that actually created an access method to the database that LOOKED like an object model. Heck, should be no problem, after all this is kind of what ORMs are trying to do - create an updateable "view" of the database for the client to use to update the server. Heck, here's a crazy idea - why can't the server update the "view" in the client, if we always had an open connection (see long polling?). Well, at least if the impedence mismatch of needing SQL to get from the code to the database was not there (rather an "object interface"), things are a little nicer.

      Also, imagine a dynamic object, for example - one in which you can just set the value of a property, but in the programming environment, you can intercept that operation and see oh, look, this is Person # 123 and the property Last Name is being set, why, I'll go update the database while I update the object. Imagine all changes to data in objects going straight through to the database instead of going through a complex ORM layer (yes, of course, too much traffic to the database with millions of little writes?). This is what happens when the database, and the code, are directly connected. And no, the object doesn't have to LOOK like the database, although it can. Just like a view doesn't need to look like the tables it represents, although it can. Also note, updateable views are possible when a SQL engine can determine how to decompose an update and update related tables (although almost no database can do it when there are joins involved). So updateable objects that work like views seem totally doable. Ironically, already kind of done if you consider MUMPS for example, which had persistent storage by simply going: SET ^Person("123","LastName")="Bob", right in the language itself - just didn't look like a strongly typed object.

      Ironically, I am actually a strong relational supporter, and have personally built at least one major relational database that scaled up to several terabytes in the area of large scale fraud detection. So, I am familiar with, and have a deep respect for Boyce, Codd, Chris Date, the relvar, relational algebra and set logic, Inmon, Kimball, data warehousing, OLTP vs OLAP, to name a few.

      I am not a "node.js" front-end web cowboy with no understanding of database technology..... and boy, did I have my fill of database replication, in SQL Server, specifically. It worked, but it could be a bear at times. I urge you - if you haven't looked into what the latest distributed relational databases can do (or even go back to Teradata which is expensive but has a long history of distributed scaling) - ACID is totally possibly, performance can be increased, and it's nowhere near as difficult as replication - it DOES work. It turns out that relational operations work really well at being decomposed and distributed in a similar fashion to map/reduce algorithms (see the work of the late Dr Jim Gray, a former top database researcher from Microsoft).

      Furthermore, I am currently working a job using a legacy MULTIVALUE database - for fun, if you haven't read up on Pick/D3 or OpenQM, check them out. Most people don't even know what a MV database is, but to understand where I'm coming from, you'd need to know more about the history of what well could have been if a few technology choices had been different in the past. Not to say I'm unhappy with how things did turn out - I think every technolog

  4. Too bad. by owenferguson · · Score: 1

    So sad that my Opa died before he got to see this software project in his honor...

  5. what the which? by adavies42 · · Score: 1

    acronym overload, somebody call AAAAAAAAAAA!

    --
    Media that can be recorded and distributed can be recorded and distributed.
    -kfg
  6. It has a very unfortunate name. by Anonymous Coward · · 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".

  7. Just because you have a hammer.. by greywire · · Score: 2

    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)

    --
    -- Senior Software Engineer, Attorney appearance services, locallawyerapp.com.
    1. Re:Just because you have a hammer.. by koper · · 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?

      • easy mapping of all (including user-defined) language data-types into the database (so that it's easy to persist any that in your program),
      • a syntactic layer on top of that (so that it all look pretty & super easy) and
      • a strong type-checking of Opa on top of all this (to make sure that your data stays true to the "schema" declaration and that strong-typing guarantees extend to the persisted data)

      What's not to love? ;)

    2. Re:Just because you have a hammer.. by phy_si_kal · · Score: 1

      Sorry, I am probably the one to blame with the 'ORM' keyword ;)
      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 build applications that run in the modern browsers.

    3. Re:Just because you have a hammer.. by greywire · · Score: 1

      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.

      --
      -- Senior Software Engineer, Attorney appearance services, locallawyerapp.com.
  8. And I say by Anonymous Coward · · Score: 0

    TDF works nearly as will using WP-88 on he EIEIO

  9. BFD, WTF, make it stop by Bodhammer · · Score: 1

    I didn't RTFA but it sounds double-plus ungood to me, Help me not it will...

    --
    "I say we take off, nuke the site from orbit. It's the only way to be sure."
  10. I call BS by fusiongyro · · Score: 1

    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 any document store and make the same claims.

    The actual problem underlying the O/R mismatch is that the relational database is a high-level, declarative tool. How do you wrap something high-level in something low-level? You don't, or you reimplement 90% of it. The ORMs that make egregious assumptions and overcomplicate things are the problem (I'm talking about ActiveRecord and Hibernate). There are other, better ORMs which work because they have an appreciation of the difficulty of the task and actually attempt to bridge the gap (yeah, SQL Alchemy).

    The problem is overhyped and so is the solution.

    1. Re:I call BS by Sarten-X · · Score: 1

      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 databases) are not intended for instantaneous and atomic validity. They are intended for use cases where absolute accuracy doesn't matter, but the parallelism of a cluster running a MapReduce algorithm does. No, it doesn't matter if a hundred messages were missed when the latest trends were calculated. It doesn't matter if a few website crawls were missed when the index is generated. They'll be included next time, and the loss of integrity has a trivial effect on the final result.

      Sure, any RDBMS can be finely-tuned for each algorithm it will need to support, and with enough $100,000 machines it'll be able to process the necessary queries. On the other hand, that time and financial investment could be put into programmers to adapt the algorithm into a more scalable system, so when the service goes from 10,000 users to 10,000,000, and you go from having a million rows per table to a few billion, you don't need to spend 1000 times as much on server hardware.

      That's the "web scale" hype the NoSQL fans use, and the only problem with its use is that 75% of projects using NoSQL don't really need it, and never will. Many of them will never really grow beyond the need for more than a flat-file store. That's no reason to discourage its development for the 25% of projects that have a shot at growing that big.

      The actual problem underlying the O/R mismatch is that there are two high-level tools trying to interact without being perfectly matched. There are no "low-level" tools involved. The simplest solution is to use only a subset of one tool, which is what most ORMs do. The difference between the "problem" and the "better" ORMs is the size of the subsets they implement, and the elegance with which they do it.

      --
      You do not have a moral or legal right to do absolutely anything you want.
    2. Re:I call BS by koper · · 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 and MongoDB are a good match here so that this "ORM" (no, it's not an ORM but it's a data-mapping between data representation in the language and in the database) is simple and natural. Finally we provided tailor-made syntax on top of all this, which makes it all look super easy and concise.

  11. MongoDB, SchmongoDB, Opa's the real story here by sticks_us · · 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.

    http://opalang.org/

    I had a few complaints about it early on, but it's evolving, though. Might be worth revisiting.

    --
    "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth
    1. Re:MongoDB, SchmongoDB, Opa's the real story here by koper · · 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!

  12. Object-Relational Impedance Mismatch and NoSQL? by Anonymous Coward · · Score: 0

    If MongoDB is not a relational database then how on earth can it suffer from object-relational impedance mismatch?

    1. Re:Object-Relational Impedance Mismatch and NoSQL? by koper · · Score: 1

      The term is used here in a broader sense of mapping between data representation in the programming language and in the database.