Live data from Hacker News

A routine gem update ended up creating $73k worth of subscriptions

serpapi.com

11–20 of 336 posts

Re: A routine gem update ended up creating $73k worth of subscriptions

#14
post #6

Mongoid docs[1] seem to be pretty cool about this change: "As of Mongoid 7.1, logical operators (and, or, nor and not) have been changed to have the the same semantics as those of ActiveRecord. To obtain the semantics of or as it behaved in Mongoid 7.0 and earlier, use any_of which is described below." Is it just me or is this one of the most terrible breaking changes in a popular, official library ever? [1] https://…

Perhaps before 7.1 Mongoid had a problem that the logical operators acted differently to ActiveRecord. But come on, this adjustment could have been implemented in another namespace or something...

Re: A routine gem update ended up creating $73k worth of subscriptions

#15

Earlier quoted context omitted.

I shun everything MongoDB because of how immature its engineering culture is.

Can you explain?

I can't explain for the other user but I'll tack on my own little horror story. I once got the task of porting something written for early nodejs that used MongoDB as a backend to Django. The app had been developed by a contractor and had many iterations of the data layer. I had to somehow make sense of how to make that all fit in a relational database. The changes made were not documented at all and I didn't have time to go digging through the git repo for some history. It was not a particularly fun task.

Maybe it's a culture thing. I have this oldschool thing about data meeting invariant criteria and I dislike not using a RDBMS.

Re: A routine gem update ended up creating $73k worth of subscriptions

#17
post #6

Mongoid docs[1] seem to be pretty cool about this change: "As of Mongoid 7.1, logical operators (and, or, nor and not) have been changed to have the the same semantics as those of ActiveRecord. To obtain the semantics of or as it behaved in Mongoid 7.0 and earlier, use any_of which is described below." Is it just me or is this one of the most terrible breaking changes in a popular, official library ever? [1] https://…

It's clearly a breaking change how a core feature of the library behaves. This is extremely unprofessional on the part of the maintainers. I'd completely lose trust in the gem.

They knew they were making a breaking change, documented it, and didn't increment a major version number. That breaks the entire point of semver.

Also, this is generating SQL ffs. Like how more nasty of a breaking change could you make in terms of potential impact to live apps that upgrade? The experience in the post is a perfect example of how badly this can go wrong.

Re: A routine gem update ended up creating $73k worth of subscriptions

#18
Of note -- their company services seem to be that you pay them to return you Google search results via API.

Isn't that against the Google search Terms of Service???

If google wanted there to be a paid search api, I'm pretty sure they would just provide one.

Also, I'm pretty sure I've seen these types of startups before, and then they vanish quickly thereafter....

Re: A routine gem update ended up creating $73k worth of subscriptions

#20

That sounds like a major, incredibly dangerous update to the DB driver. Their 7.1, 7.2, 7.3 versions seem to all have breaking changes [1]. Yet they are in obvious violation of SemVer expectations, which they declare to follow [2]: > Mongoid follows versioning guidelines as outlined by the Semantic Versioning Specification, so you can expect only backwards incompatible changes in major versions [sic] [1] https://docs…

To be fair, the your second link points to the documentation of an ancient version; the new docs don't seem to mention semver (I still don't think what they are doing is reasonable, but ...)
Post reply on HN