It's not about the databases, it's about the migration in the first place.
If you have a problem that can be solved best with a graph database, then there is no problem. Many problem can be better solved with a graph structure. Choose one, and you'll be happy.
But, if your use-case is migrating from MongoDB to a graph database, that's a bit of a red-flag. What data model do you have where you can migrate from a document/schema-less system to a graph database? Maybe the tech lead figured out that a graph model works better for your data. If that's the case, then great -- migrate away.
But given that they want to go from Mongo to a graph DB, the fear is that this is someone who is only chasing the next cool technology and not solving an underlying business problem.
>But given that they want to go from Mongo to a graph DB, the fear is that this is someone who is only chasing the next cool technology and not solving an underlying business problem.
To be fair to the teach lead, I do feel like it was the other way around. MongoDB was foisted on us on a new project (we were previously SQL) by a software architect who left soon after. I've never felt that MongoDB was a good fit for what we want to do, but I want to return to SQL.
New tech lead pushing switching an existing product from infamously-cargo-culted MongoDB, of the much-hyped-but-now-passed Document Databases Are The Future wave, to either of a couple products in the current "X database architecture is The Future" wave? Does that not read like it could just as well be straight-faced parody, as real? The products may be fine, so far as they go, that's not what I'm trying to puzzle out here.
In my experience MongoDB has only given me problems (either performance or data loss). Most likely when someone wants so "solve" something with MongoDB, there is always a better technology to do it (Cassandra, ScyllaDB, S3!, PostgreSQL/JSONB). I could Imagine that their current implementation has a half modeled graph-like structure in MongoDB and migrating to something else (I am generally against Neo4J because of their horrible pricing tiers).
they are a solid product - graph and document is a good mix. don't listen to the negative postgres fundos (especially ones who don't understand what a solid and performative database Mongo has become)
The most recent graph DB I've used was Dgraph, I've found the interface to be good to work with and it does scale well performance wise. Memory consumption was still too high for my tastes and if you need to build common algos on top like PageRank, again for example, they don't support that out of the box. If you read through their forum you'll see they may never choose to support things like that natively so you have to do things like I did which was export the data out. This was maybe 7 months ago now.
I'll also say that working on the entire graph if you need to is difficult, they're not oriented around working on the whole more like fragments that you've paired down through your query modifiers so if you know you're going to be doing a lot of work that requires you to do things on the entire graph that may change the performance characteristics for you a lot.
I like it and would use it again but there are rough edges to work around still and it is young so know your use case and know the trade offs you're making.
We use ArangoDB and are super happy. But I guess it depends on your use case. We operate in the area of 1 million records. Everything is super fast and the ability to also have search, graph and document workloads was most important for us.
We used ArangoDB at my previous job. I liked it, though it was my first engineering job so I didn't get deep into the technicals. I thought it had a nice UI and query language
>They're deliberately trying to get people to take on debt rather than just do card payments
So what? It's 0% interest. It's incredibly helpful to have easy-access financing to split purchases across a few months.
>even simple things like buying a book through a web site requires declining several offers for paying with credit.
This sounds so specific it seems like you're taking a bad experience with one website and pretending all websites are like this. Most e-commerce sites I've used in the past year offer Klarna or some similar service and all of them have been implemented as just another option in a set of radio buttons.
> It's incredibly helpful to have easy-access financing to split purchases across a few months.
I don't know, it seems like a failure at adulting to have to do that for small to medium sized purchases. If you need the feature, you probably should not have it available. Maybe this is my German attitude about money - basically, only take on debt for investments, a notable example being housing.
> So what? It's 0% interest. It's incredibly helpful to have easy-access financing to split purchases across a few months.
Unfortunately, this often isn't the case of people who are worse off, not good at managing their finances, and often overwhelmed by bureaucracy.
They fall behind on payments, and then get taken to the cleaners on fees, deferred interest etc., often paying several times the actual price of the product. I've seen this happen (with different but similar services).
Less savvy people being sold stuff they can't afford on credit has been such a problem that some countries have made it illegal to extend credit to someone who can't afford it, which is obviously extremely hard to enforce.
This is hard to grasp for many here, because HN readers tend to be well above average intelligence. Try to think in terms of "imagine how dumb the average person is, and now realize half the people are dumber than that". Now add mental or physical health issues into the game.
Debt is slavery and so on. Let's not get too hung up on the fact that I dislike it.
> Most e-commerce sites I've used in the past year offer Klarna or some similar service and all of them have been implemented as just another option in a set of radio buttons.
Radio buttons is fine. It's the defaults and "are you sure you don't want to pay with credit?" questions I'm bugged out about. I don't have an issue with them offering it as an option. I've seen it with multiple websites using Klarna for payment handling.
I agree, but just to clarify: inability to pay one's debts has historically been one of the primary ways into forced labour with unfavourable conditions. A bit away from slavery still, but not a completely out of the air connection.
You missed the point. It was a deliberate simplification (hence a simplification of a biblical quote and the addition of "and so on") intended to steer the focus away from my personal opinion about debt, and towards the second point, i.e. dark patterns in order to get people to pay with credit rather than with a debit card.
Because - per the pattern of behavior we're discussing in this thread - some developers close old issues, whether they were actually resolved or not, and it's becoming a common practice, particularly with the appearance of bots performing this function automatically.
Also, not everyone is using the most recent release.
Some issues are not actually bugs but user errors (e.g. because they haven't read the manual). Personally I'm not sure if it's better to close such issues or keep them open with a special label.
I do, because I realized people close stale issues just because (and then there are bots that do it now too). I'm happy I can still do it, and I worry that one day someone will have a bright idea to "archive" closed issues to where they cannot be easily found.
AFAIK, Gmail has suffered on the order of 100x+ fewer security incidents than Outlook. However, I am unclear on the distinction between cloud Outlook and the Exchange/Outlook combo. So me saying "Outlook" may be a mistake, and the correct term may be Exchange.
The idea that they have been "bypassed" is indeed a fabrication. That phrasing implies that long-term studies are usually carried out in vaccine trials and an exception was made for COVID-19 vaccines. That is not the case. Long-term studies are always carried out after a vaccine has already hit the market.
It would be correct to say that no long-term studies have taken place, not that they have been "bypassed."
Recommending the standard set of modules is the opposite of "going simple." Poetry removes a lot of the complexity and user-unfriendliness inherent in the previous set of standard modules. For any Python beginner coming from another popular language Poetry is likely going to be very similar to the dependency and package management in the language they're coming from. Python's standard set of modules sticks out like a sore thumb when compared to the tools in other popular languages.
