• Greg (unregistered)

    I'm not sure the statement "But the query definitely should have returned results." is correct when the sql query contains a syntax error...

  • (nodebb) in reply to Greg

    I understood it as meaning "the intended query"...

  • dusoft (unregistered) in reply to Greg

    Result of SQL query could be also an error. You want it returned instead of hiding it quitely.

  • (nodebb)

    Also, your database should be able to alert you to these kinds of things, so that it doesn't live in your code anyway.

    The database can alert you to queries that take a long time to execute, but it doesn't know how much time is spent in the network in between the application and database, so the database's number is less helpful when trying to figure out why some specific request to the app took a long time to return results. Having both numbers is ideal, since they're good for different things.

  • (nodebb) in reply to Balor64

    The database can alert you to queries that take a long time to execute, but it doesn't know how much time is spent in the network in between the application and database.

    The log warning is specifically about a "long query". I don't think whoever wrote that even considered such details as network latency.

    The entire function smells of lazy convenience wrapper anyway.

    Why bother handling errors? Too much repeated work. Let's just not surface them.

    "That one time I needed to debug a long query" so let's just bake it into the wrapper forever.

    Why bother have 2 functions when one vs multi results can be combined. It's DRY! No but whatever -- I've had seniority code reviewers forcing me to "merge and factorize" functions like that.

    It's a helper method, right?

Leave a comment on “Caught a Mistake”

Log In or post as a guest

Replying to comment #700530:

Log Out

« Return to Article