• (disco)

    Our Discourse forum has received a mixed approval rating. Many folks like it, but others still find it lacking in areas in certain clients. Well, no matter your opinion, I can guarantee that, as it was true when the article first ran, our forum doesn't have the same problem mentioned below.

    “Discourse: It’s better than some random TDWTF-front-page forum code”

  • (disco)

    When working in a develop-struction environment, it is very tempting to code in these kind of patches to the database to make sure the code will be compatible. Of course a better approach is to have a specific admin function or page which can intelligently analyse and upgrade the underlying database to support the current code version. I work in vertical integration which basically means shoe horning new features into a warehousing application as requested by clients. The software allows the database to be customised with new tables and new fields in certain core tables. Sometimes different databases have similar customisations implemented in different ways. E.g one uses a checkbox and the other has a drop down control with two options. Lots of fun when it comes to writing reports which need to work with both structures. Hopefully I have never written code that does the same field check for every record in a table as in the article. Interestingly, the application provides a screen editor for altering the control layout on certain screens such as stock and customers. Adding or removing a control updates the field on the underlying table. Saving the screen changes can take 5-15 minutes on a large table. Clearly every record needs to be touched somehow to make the change. But if we use the Sql application provided by the dbms vendor, the same tables can be altered in seconds.

    I think the moral of the story is to use a "real world" dataset for testing that way if you make a goof it will at least be obvious.

  • (disco)

    How could it possibly be slow? They're using a cache!

  • (disco) in reply to VinDuv
    VinDuv:
    Discourse: It’s better than some random TDWTF-front-page forum code

    Cite please

  • (disco)

    "Having recently upgraded my forum software," Kinta wrote, "I noticed that *"

    "Upon further investigation, I found that that the following code was being run once for each and every comment on a page, whenever ever a forum thread was opened.

    https://github.com/discourse/discourse/blob/537e6b193d1208ee781599e37138046ddfede8cb/app/assets/javascripts/discourse/dialects/bold_italics_dialect.js

  • (disco) in reply to hungrier

    So now we know. 8675309 is a word made up of letters. And that's why Tommy can't get hold of Jenny, because he needs a number and all he's got is a word.

  • (disco)

    When I clicked on the topic link I thought this was going to be about a wooden table. I'm disappointed...

  • (disco) in reply to Kim_Groves

    Even in a development environment, I hope you never go around with database credentials and setting up a connection for each and every method that requires database interactivity. Let alone store separate connection references in each single object. This is first-year-developer garbage code, no matter how you look at it.

    Also, software that dynamically modifies its underlying data model? That's a darn good sign that your data model needs revising. It's also a surefire way to create completely unmaintainable software really, really fast, if you are after job security.

  • (disco) in reply to VinDuv

    Our Discourse forum has received a mixed approval rating. Many folks like it, but others still find it lacking in areas in certain clients. Well, no matter your opinion, I can guarantee that, as it was true when the article first ran, our forum doesn't have the same problem mentioned below.

    “Discourse: It’s better than some random TDWTF-front-page forum code”

    How do you know? It does stupider things than this. And I had to manually type in what.thedailywtf.com/raw/5173/3 to figure out how to get it to post your quote without breaking the formatting.

  • (disco) in reply to Keith

    Well, ummm, yeah, they are using a cache...

    The problem arises because they're not using a cache to verify the cache. They need a cache cache.

    ...or is the proper term "meta cache"? Hmmmm.....

  • (disco) in reply to VinDuv

    I've decided to like your post:

    [image]
  • (disco) in reply to Zecc
  • (disco) in reply to Luhmann

    My screenshot is from Firefox. Tried Chromium and it's not happening. Can't be arsed to try other browsers or machines.

  • (disco) in reply to Zecc
    Zecc:
    My screenshot is from Firefox. Tried Chromium and it's not happening. Can't be arsed to try other browsers or machines.

    I figured as much but I couldn't be arsed to do anything else than take a screenshot of your screenshot showing that it didn't do the thing it does on your end.

  • (disco) 
    --cache invalidation
DROP TABLE item_cache;
  • (disco)

    Who knows if the release team has been applying our rollout scripts? Better safe than sorry!

  • (disco) in reply to FragFrog
    FragFrog:
    Also, software that dynamically modifies its underlying data model? That's a darn good sign that your data model needs revising. It's also a surefire way to create completely unmaintainable software really, really fast, if you are after job security.

    Depends. An example is a plug in that might be applied to something where a maintenance failure by an out-of-my-control DBA might mean that the plug in is running against an obsolete database schema. In this case, it makes sense for the plugin when first run to verify the parts of the schema to which it needs access, and depending on circumstances either silently update the schema or to exit with a suitable warning as to why it cannot run. Any code that may go into an SME environment has to assume that the kind of support you get in a large enterprise may not exist. So long as there is a process such that every schema change to deal with an enhancement results in correct update code being put in the plugin validation, the software is far from unmaintainable.

  • (disco) in reply to JBert
    JBert:
    When I clicked on the topic link I thought this was going to be about a wooden table. I'm disappointed...

    wooden tyou just know someone would try to make that joke.

  • (disco) in reply to kupfernigk
    kupfernigk:
    [...] it makes sense for the plugin when first run to verify the parts of the schema to which it needs access, and depending on circumstances either silently update the schema or to exit with a suitable warning as to why it cannot run.[...]
    Perhaps I should have clarified that I meant data model updates during normal operation: I would qualify your example as an installation procedure, in which case schema updates make sense. But even then I would be skeptical; either the relevant parts of the schema are not shared with other modules, in which case the plugin could well be contained in its own schema, or they *are* shared with other modules, which means that updating one plugin can break another plugin. You would need to create a dependency-list and verify that all components may be updated as well before proceeding - similar to what APT does for example. Simply going "what the hey, I need this schema modified, so let's do it!" will sooner or later break stuff.

Leave a comment on “Classic WTF - Yes, The Table is Still There”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article