Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

Soulskill posted more than 2 years ago | from the new-and-shiny dept.

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

cancel ×

29 comments

Mongo stay with Sherrif Bart (3, Funny)

NoNonAlphaCharsHere (2201864) | more than 2 years ago | (#39116869)

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

Is it still web scale? (0, Funny)

Anonymous Coward | more than 2 years ago | (#39116913)

Re:Is it still web scale? (0)

Anonymous Coward | more than 2 years ago | (#39117115)

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.

It has a very unfortunate name. (1)

Anonymous Coward | more than 2 years ago | (#39117447)

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.. (2)

SixDimensionalArray (604334) | more than 2 years ago | (#39117081)

...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:When programming tools and databases meet.. (1)

DiegoBravo (324012) | more than 2 years ago | (#39117283)

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:When programming tools and databases meet.. (1)

RareButSeriousSideEf (968810) | more than 2 years ago | (#39117733)

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:When programming tools and databases meet.. (1)

VortexCortex (1117377) | more than 2 years ago | (#39117955)

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!

Re:When programming tools and databases meet.. (1)

SixDimensionalArray (604334) | more than 2 years ago | (#39118841)

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.

Re:When programming tools and databases meet.. (1)

WaffleMonster (969671) | more than 2 years ago | (#39118889)

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.

Re:When programming tools and databases meet.. (1)

SixDimensionalArray (604334) | more than 2 years ago | (#39119331)

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!

Re:When programming tools and databases meet.. (1)

fusiongyro (55524) | more than 2 years ago | (#39120911)

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. [apple.com] 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" project, I believe you could make something that could compete with or match a traditional relational database in any one area: speed, integrity, storage performance, feature set or whatever dimension you like. But it will suck eggs for every other parameter. And indeed, if you look at the popular NoSQL databases that is what you see: a fast one that loses data, a slow one that doesn't, one that has great conflict resolution, and so forth. You choose one of these and you are essentially saying, "yeah, we're never going to care about that other stuff." At least not for 5, 10 or 15 years. But how often do your requirements change? More often than that, perhaps? And how many of these databases are going to be around in that length of time? CouchDB didn't even make it to its 6th birthday before being forked and losing the primary author. If you're in it for glory, you're not in it for the long haul.

Using a relational database, you're not just subscribing to some sort of death by SQL. You're buying into decades of work by truly hardcore engineers who did not do it to get famous (oh, don't worry, I'm not talking about Monty!) You're dealing with really solid software that has been proven in production for ages.

all progress depends on the unreasonable man!

You know, it's sort of true. After all, E. F. Codd was once that guy, and it was literally more than a decade before there were databases that performed adequately. The difference is that Codd started with the math, showed that it could be possible and that it would be a win, and then after enough time and energy was invested, it became feasible, and then awesome. This is the opposite of what's going on with NoSQL: a rejection of what came before from front-end developers who probably couldn't take a derivative if their life depended on it, 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.

I'd find it a lot easier to put stock in these dreams if I thought they weren't, fundamentally, about undermining forty years of progress for the sake of a little venture capital today, but that's exactly what I see: everybody talking about scalability is either a scalability engineer at one of the big N where it actually matters, or, more likely, some moron who thinks they're going to take over the internet in six months with their stupid knockoff variation. And of course they want the answer to be simple, because if the answer is complex they don't stand a chance. Unfortunately, the answer is very subtle. Simple and subtle look related but are actually quite different.

Re:When programming tools and databases meet.. (0)

Anonymous Coward | more than 2 years ago | (#39121347)

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

Re:When programming tools and databases meet.. (1)

SixDimensionalArray (604334) | more than 2 years ago | (#39121757)

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 [wisc.edu] , 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 technology is unique and interesting, but I have a fairly reasonably different viewpoint because of working with older technologies, and newer ones both.

I also agree that, I personally feel that the acronym NoSQL (which we have been told really means "Not Only SQL") was actually really something different, a bit of an underhanded jab - I think they should have called in NoRelational - because that to me seems to be a deeper crux of what is really going on here. After all, SQL is a query language - who cares what database it runs against (although it clearly was designed with relations in mind), but that doesn't mean it necessarily had to run against a relational database. Ultimately, NoSQL is another technology for the toolbag, and a new direction for people to research.

I am interested in what could be (as evidenced by my "dreaming"). I see, based on our short memory of past history, our long recent successes with relational databases, and the new developments in NoSQL databases, a new possibility - some sort of hybrid which is a mix of technologies, and something that truly can achieve a lot of aims that we all have (distributed systems, connectivity, less mismatch, data integrity, etc). And I see this possibility manifested in the kind of thought that happened in this Opa project. New thought should be encouraged, not discouraged, and hopefully, these new thoughts root themselves in solid solutions and learn from the past as much as they look to the future.

Too bad. (1)

owenferguson (521762) | more than 2 years ago | (#39117187)

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

what the which? (1)

adavies42 (746183) | more than 2 years ago | (#39117371)

acronym overload, somebody call AAAAAAAAAAA!

Just because you have a hammer.. (2)

greywire (78262) | more than 2 years ago | (#39117473)

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:Just because you have a hammer.. (1)

koper (2179858) | more than 2 years ago | (#39127447)

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? ;)

Re:Just because you have a hammer.. (1)

greywire (78262) | more than 2 years ago | (#39128499)

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:Just because you have a hammer.. (1)

phy_si_kal (729421) | more than 2 years ago | (#39127509)

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.

And I say (0)

Anonymous Coward | more than 2 years ago | (#39117533)

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

BFD, WTF, make it stop (1)

Bodhammer (559311) | more than 2 years ago | (#39117921)

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

I call BS (1)

fusiongyro (55524) | more than 2 years ago | (#39118269)

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.

Re:I call BS (1)

Sarten-X (1102295) | more than 2 years ago | (#39124907)

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.

Re:I call BS (1)

koper (2179858) | more than 2 years ago | (#39127593)

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.

MongoDB, SchmongoDB, Opa's the real story here (1)

sticks_us (150624) | more than 2 years ago | (#39119799)

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:MongoDB, SchmongoDB, Opa's the real story here (1)

koper (2179858) | more than 2 years ago | (#39127611)

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!

Object-Relational Impedance Mismatch and NoSQL? (0)

Anonymous Coward | more than 2 years ago | (#39122389)

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

Re:Object-Relational Impedance Mismatch and NoSQL? (1)

koper (2179858) | more than 2 years ago | (#39127627)

The term is used here in a broader sense of mapping between data representation in the programming language and in the database.
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...