91–100 of 130 posts
I’m still waiting for the NoSQL crowd to realize that the best use case was always handled by CouchDB.
I started picking up CouchDB and PouchDB and the DX is fantastic. Always wondered why there’s never been any hype or more examples around this stack?
Earlier quoted context omitted.
Because PostgreSQL Is fantastic Open Source database engine, very popular with a lot of operational experience and tooling support. This is Open Source way of doing things - having project focus on as narrow problem as possible (first) and leverage as much of existing componets as possible.
Cramming an api for one product on top of another is absolutely not “the open source way” I’d expect a much better explanation for this Frankenstein’s monster. This seems like it would work but never scale.
If you roll everything yourself, you pretty much have to reinvent everything PostGres has except the SQL and relational aspects.
Earlier quoted context omitted.
It may also mean poor schema design. You can absolutely model relational data in MongoDB without relying on joins. If you want to normalize your data don't pick Mongo.
If you aren't normalizing, how are you ensuring that you don't avoid anomalies?
You choose relational models when anomalies are unacceptable and non-relational models when anomalies are acceptable.
Earlier quoted context omitted.
There are 3 "competing" Open Source and Free Software definitions - from OSI, Free Software Foundation and Debian. MongoDB does not match any of them and most importantly does not match the spirit of Open Source Software Movement.
I could name more, but let me clarify something. I’m not a fan of the SSPL, but I get why it was necessary. It was rough seeing huge cloud providers profit off open source projects without giving anything back. When they offered competing hosting services with no value added (well, past “integrated billing”), no contributions or innovation, and drove their new customers to the documentation and libraries of the compa…
You mention Elastic - do not forget it was built on top of Lucene, capturing most of the value in that project.
It DOES very much impact users because users increasingly want DBaaS experience and if the only one you can get is through MongoDB or MongoDB authorized partnershp it is really no different than proprietary software.
In any case I agree for certain users SSPL is just a good as Open Source, same however can be said about Proprietary Software - some who just "buy subscription" do not care.
Earlier quoted context omitted.
SSPL goes way beyond AGPL as it contains an additional clause called "Offering the Program as a Service". It is not defined at all what constitutes providing MongoDB as a service. How many layers are needed to abstract MongoDB in a way that it doesn't trigger this clause? There are no answers for that in the SSPL. It comes with an enormous amount of risk compared to AGPL. There is a good article from Dor Laor at Scyl…
AGPL is basically the same thing, except far more reaching. AGPL, to my understanding, makes it a requirement if you allow people to use the software via network levels. “Program as a Service” seems a lot more limited in scope. All new licenses come with risk since the decisions can only be made via court decisions.
This was benefit for users but obviously not something classical corporaton would enjoy
Earlier quoted context omitted.
Yes and custom network software for routers, switches, firewalls, and custom OSes etc.
Those aren’t listed are they? The idea you need to release code for the os, file system, network routers, etc is absurd.
Let's say you decided to run MongoDB as a service, and you are fine with releasing Service Source Code under SSPL. The problem is – you can't. You don't own the source code for your NAS and can't relicense it. Nothing in the text says, "relicense all you can, and then you are fine". Clause 13 puts requirements on software that are completely unrelated in terms of copyright.
> I am confused. If you use a custom storage system then you would have the code for it. No?
Nothing in the license text says that the storage system has to be custom.
> The idea you need to release code for the os, file system, network routers, etc is absurd.
I agree with you that this is absurd. But that's what the license text says.
I suggest you read section 13, not MongoDB's FAQs or other explanations of how it works. The actual legal tech is very different from what you seem to think it is.
Earlier quoted context omitted.
Yes, FerretDB is a layer which implements the MongoDB wire protocol on top of Postgres. Right now we are using JSONB, but this affects performance and we need to depart from this strategy in the long run. We have an article which explains the concept [1]. I wouldn't go into the document vs. relational argument, all arguments for and against would have merit. There are valid use cases for document databases (take e-co…
I'm curious about what makes document databases a good fit for e-commerce. I've never worked in that industry.
1. Denormalized data is often a boon. One of your key use cases is "give me all the information about this Product so I can show it to the user." Forget joining a ton of tables, just do 1 read of 1 product and go on your way.
2. A certain amount of more freeform data is expected. Different product categories will have different sets of information. T-shirts and drinkware both have sizes, but these sizes have nothing to do with each other. You can model all this in a traditional SQL database, but you have to stop and think really hard about it, and potentially end up with a plethora of tables. In a document database, it's much easier to just add the data and go on your way.
Earlier quoted context omitted.
SSPL goes way beyond AGPL as it contains an additional clause called "Offering the Program as a Service". It is not defined at all what constitutes providing MongoDB as a service. How many layers are needed to abstract MongoDB in a way that it doesn't trigger this clause? There are no answers for that in the SSPL. It comes with an enormous amount of risk compared to AGPL. There is a good article from Dor Laor at Scyl…
AGPL is basically the same thing, except far more reaching. AGPL, to my understanding, makes it a requirement if you allow people to use the software via network levels. “Program as a Service” seems a lot more limited in scope. All new licenses come with risk since the decisions can only be made via court decisions.
AGPL requirements do not trigger if you don't modify the source code. The relevant text is in section 13:
> […] if you modify the Program, your modified version must prominently offer all users […]
See also [1], [2], [3].
> “Program as a Service” seems a lot more limited in scope.
AGPL scope:
> The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work.
Basically, the software itself and build scripts.
SSPL scope:
> “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
As noted in another thread, that's not only beyond the scope of the software itself – it is beyond the scope you _can_ relicense and arguably beyond the scope of the copyright terms themselves.
[1] https://opensource.com/article/17/1/providing-corresponding-...
[2] https://fossa.com/blog/open-source-software-licenses-101-agp...
[3] https://opensource.stackexchange.com/questions/650/do-i-have...
Earlier quoted context omitted.
If you aren't normalizing, how are you ensuring that you don't avoid anomalies?
Proper NoSQL design has a different perspective, it asks you "well, so what if you have an anomaly?". One example could be movies, with actors, producers, genres, etc. that could all be in separate tables in a relational database, or each movie could be a document in a document database. Now let's imagine that an actor changes their name a few years after the movie is released. Is it important to go back and change t…