251–260 of 291 posts
Earlier quoted context omitted.
Coming from Rethink and Mongo I don't like SQL. I don't want rows at all, or documentation that assumes a table model. Having a JSON data type doesn't mean you're a document store.
Postgres can do JSON. Does MongoDB have schemas yet?
Earlier quoted context omitted.
> If it had been SQL it would have been easy to drop in another database. Not true at all. Way too many organisations are locked into Oracle just because it's too hard to switch to something cheaper.
Relational/SQL databases still follow the same fundamental data model and query language, despite the differences in SQL syntax. I will argue migration is still easier. Just avoid stored procedures which complex logic, since these are essentially proprietary programming languages.
To really take advantage of a database engine, you will probably end up using engine-specific idioms.
Postgres and Sql Server support recursive CTEs. MySql probably doesn't?
Sql Server supports cursors but is dog slow and generally not recommended for any sort of large scale operations.
Isolation levels and locking are really important as well. Do all engines even support the same isolation levels?
Earlier quoted context omitted.
I feel like you’re imagining that SQL is more of a standard interface than it actually is. No two relational databases are quite the same and you’ll be stuck combing through your entire app looking for obscure syntax usage that depends on Oracle specific extensions or quirks. There’s no incentive to not extend or try to improve SQL semantics because for proprietary databases it increases lock-in which is good for sal…
I think it is probably easier to port from one SQL dialect to another, than from Mongo’s hokey JSON based query language to anything else.
We tried to do a migration from Sql Server to Postgres.
Even went as far as building a parser/compiler to transform Sql. Certain things are just too difficult to handle.
1. Sql Server supports arbitrary sql statements in queries. Postgres does not.
2. Data types are not the same.
3. Feature sets at the 'interface edge' between the client library and the engine differ. For example, Sql Server queries can return an arbitrary number of results.
It's true that Mongo uses a custom language, but with Mongo - you are unlikely to have any significant business logic in your data layer.
Also their API surface is relatively simple.
For example, FoundationDB has a layer that mimics the Mongo API. Amazon has one as well.
I'm astonished at all the comments that vilify MongoDB Inc and then talk about moving to AWS's MongoDB clone. What sort of twisted world are we living in where a company makes a service, tries to sell the service, and then are lambasted when they try to prevent a competitor from copying it wholesale? Cloud providers have been able to stand on the shoulders of giants, profiting immensely from millions of lines of open…
I am not sure that part is 100% accurate: "where a company makes a service". Are you referring to MongoDB Inc making MongoDB?
Earlier quoted context omitted.
It isn't exploitation because it is literally part of the definition of open source that other people can use and profit off of the work. Linux has made more than one company rich- do we think Red Hat is exploiting Linux? It's also unfair to pretend that companies who are setting up managed services are universally not contributing back- by open sourcing their code MongoDB has been able to benefit off of the issues t…
If someone were promoting a cause--say a business just trying to get the word out there about their new offering--were sitting at a table with a box that said "free mugs", would you consider it exploitative to take the entire box of free mugs, scrub off the company's logo, and begin selling them to people? Would you at least say that it's kind of scummy, or at the very least ethically questionable? Being technically…
Your mug analogy isn’t great. Mugs are finite in number and cost money to produce, whereas software is infinitely and freely distributable. Google running a managed MongoDB service doesn’t directly impact Mongo’s bottom line.
Furthermore, Mongo’s own managed service almost certainly runs Linux in its infrastructure. Google is one of the largest contributors to the Linux kernel, whereas Mongo makes no notable contributions. Why is it okay for Mongo to profit off Google’s open source labor without compensating them, but not vice versa?
Earlier quoted context omitted.
The idea of free software is that user can (and have the right to) modify it in any way one wants. If I found a bug in free software, I can fix it by myself or wait for someone else to fix it, or pay someone to make a fix. That's the way it works. (edit: typo)
You can do all that with Mongo's new license. It's an AGPL + AWS-is-killing-our-support/monitoring/ops-business license.
If I found a bug, and was adventurous to fix it, I can still open a JIRA and submit a PR to the project ...
Earlier quoted context omitted.
> I'm astonished at all the comments that vilify MongoDB Inc and then talk about moving to AWS's MongoDB clone. What sort of twisted world are we living in where a company makes a service, tries to sell the service, and then are lambasted when they try to prevent a competitor from copying it wholesale? The bait and switch strategy is deceptive. It's aim is to milk customers to give some money back the the VCs. But th…
It's not really a bait and switch. They didn't use an Open Source license with the intention of getting popular and then pulling the rug out from underneath users. They tried to make their money by offering their tech as a service and found that they couldn't compete against the resources of large cloud providers who were happily profiting off of their (and the community's) hard work.
And now the community's hard work is licensed under a new and restrictive license which, due to legal constraints, cannot be used in entreprise setups.