• Bittle Tobby Lables (unregistered) 
    private Fristable validateFrist (List<TDWTFReaders> fristContainers) {
    if (!validateFristness) {
        log.trace("validateFrist == false -> skipping validation");
    } else {
        log.trace("I'm frist, and so is my wife")
    }
}
  • (nodebb)

    Neglecting "getting into the problem", just having the raw data and distinct (no need for sets explicitly), just see if the counts are the same....

  • David Karnok (unregistered)

    That code is a WTF on its own if you know a bit about RxJava, blocking and share.

  • Lothar (unregistered)

    I've found this snippet in our codebase and it's been in there since 2020, about 2 years before I joined this team.

    So Remco's joined the team last week?

  • (nodebb) in reply to Lothar

    That means he will find a lot more real soon. :)

    I'm accepting bets on whether a) this company made an informed decision to use NoSQL because it satisfied their requirements best, or 2) jumped on the techno-babble buzzword-wagon without thinking about it any longer than the 5 minute speech when it was announced.

  • Brian (unregistered) in reply to Mr. TA

    Been there. Worked for a company that decided to go with a NoSQL DB because it supposedly had better performance for large datasets, and then proceeded to store mostly relational data in it. Which of course led to the huge performance drain of doing lots of joins and stuff in the application space instead of, y'know, using a DB engine that's designed to handle those things efficiently.

  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered)

    I wonder how this got past code review?

    That's easy, there was no code review.

  • NotAThingThatHappens (unregistered) in reply to Brian

    Ooh, I knooow, right?

    It's infuriating to know what's a good tool (or the wrong one), or how something should be done to have a (mostly future proof solution), and nobody believes you.

    En then suddenly I am the crazy one for not wanting to build a "one-to-one solution" for a "one-to-many problem".

  • (nodebb) in reply to Lothar

    I've found this snippet in our codebase and it's been in there since 2020, about 2 years before I joined this team.

    So Remco's joined the team last week?

    Strangely enough, today is August 10th, meaning he could have joined up to eight months ago without making his statement false.

  • Yikes (unregistered)

    Reading this code is the CS equivalent of watching a puppy hump a sofa.

  • Drak (unregistered)

    So he should have collected all non-null customer id's, put them in a distinct set, and checked the length of that set to the length of his original result?

  • (nodebb)

    This is someone like Comcast, right? Because you'd never have more than, say, a hundred customers. Right?

  • nunya business (unregistered)

    The end result is a function that takes the wrong approach to solving a problem that itself was caused by taking the wrong approach.

    The original wrong approach, of course, was using a NoSQL database in the first place. Unless you're a truly massive business (on par with Amazon, Facebook Google, Twitter, etc,) NoSQL is almost certainly not the right fit for your data needs. It's designed for scale uber alles, sacrificing everything that makes databases great on the altar of scale. If your scale isn't so big that that's an absolute necessity, it's a really dumb idea to do anything other than sticking to SQL.

Leave a comment on “Duplication”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article