• (disco)

    Reminds me of some older TDWTF articles with SQL-generated XML... I guess JSON is the new XML?

  • (disco)
    Pick your WTF: generating JSON in the database, generating JSON by string concatenation, not being more careful about sizing a `VARCHAR2` variable, or using Oracle.
    So many choices... [image]
  • (disco)
  • (disco) in reply to RaceProUK

    i don't watch the show, like at all, but why are American Dad's eyes pink?

  • (disco) in reply to accalia

    Stoned, hence snacks.

  • (disco) in reply to accalia

    I think he's stoned in that scene, hence the indecision about munchies

    Edit: hanzoed. Damn you @KillaCoder

  • (disco) in reply to accalia

    Got into crack cocaine.

  • (disco) in reply to KillaCoder
    KillaCoder:
    Stoned, hence snacks.

    ah... why did i think JPG compression artifacts when the answer was so obvious?

  • (disco) in reply to accalia
    accalia:
    ah... why did i think JPG compression artifacts when the answer was so obvious?
    ...and I outfoxed you back.

    REVENGE!!! :stuck_out_tongue_closed_eyes:

  • (disco) in reply to RaceProUK
    RaceProUK:
    ...and I outfoxed you back.

    you had an advantage. while i know what the show is i only made it through about half the first episode before saying "this is not funny. i'mma go back to watching Futurama"

    and havent watched it since.

  • (disco) in reply to accalia
    accalia:
    you had an advantage. while i know *what* the show is i only made it through about half the first episode before saying "this is not funny. i'mma go back to watching Futurama"

    and havent watched it since.

    I kept up with it for a while, but I kinda lost interest over the last year or two. The Stan-Hayley dynamic played itself out surprisingly quickly, you can only do so many crazy-Roger stories before you get sick of them, and Steve and Francine are just not interesting or developed enough as a character to hinge that many stories around. And Klaus is almost completely forgotten.
  • (disco) in reply to RaceProUK

    hmm... not really outfoxed then if i could not reliably have gotten it from context?

    as we have seen my knowledge of the show was barely sufficient for me to identify what show it was without resorting to GRIS

  • (disco)

    I'd like to complain.

    This topic was misfiled. It is currently in the “Articles” section when it clearly is a prime candidate for the IHOC.

  • (disco)

    Damnit! I have been sort of Hanzo'd and definitely DiscoScrewed. Yesterday I was going to change the topic about JSON to this exact article title, but I could not get the damned thing to load on my S5 and then later forgot about it. Now I cannot do it because it would seem unoriginal...and it probably would not allow it anyway.

  • (disco) in reply to accalia
    accalia:
    hmm... not really outfoxed then if i could not reliably have gotten it from context?
    His eyes are pink (normal cartoon shortcut for bloodshot), his expression is indistinct, and he's staring at snack foods. Kinda obvious he's stoned :stuck_out_tongue_winking_eye:
  • (disco) in reply to RaceProUK
    RaceProUK:
    Kinda obvious he's stoned

    does one buttume that i have any degree of experience with stones?

    i'm a fox ffs!

  • (disco) in reply to accalia
    accalia:
    does one buttume that i have any degree of experience with stones?

    Stones are in the woods, so any respectable fox should know something about them...

  • (disco) in reply to accalia
    accalia:
    does one buttume that i have any degree of experience with stones?

    i'm a fox ffs!

    You're an *urban* fox though, right? Plenty of stoners in cities. Plus I'm sure you could find a few hippie groups smoking pot in the woods :stuck_out_tongue_winking_eye:
  • (disco) in reply to Polygeekery
    Intercourse:
    Stones are in the woods, so any respectable fox should know something about them...

    they is gud fer sitting on to get a better view of surroundings and looking epic.

  • (disco) in reply to RaceProUK
    RaceProUK:
    You're an urban fox though, right? Plenty of stoners in cities. Plus I'm sure you could find a few hippie groups smoking pot in the woods

    what? you mean people throw stones at each other for fun and smoke cooking utensils?

    people is crazy!

    seriously though, i'm sure there is a stoner population in Protland. I've just never encountered them.

  • (disco) in reply to Eldelshell
    Eldelshell:
    [And no one has ever though about this.][1]
    JSON is cool, too, just like REF Cursors. It's the fat-free alternative to XML, and JSON data is really easy to work with in Javascript.

    Sadly not idiot-free.

  • (disco) in reply to delfinom

    That led me (ultimately) to http://www.json.org/xml.html, where I found this interesting little WTF:

    JSON does not have a `<[CDATA[]]>` feature, so it is not well suited to act as a carrier of sounds or images or other large binary payloads. JSON is optimized for data.
    I don't know about you, but I always thought that sounds and images and such were basically structured data. Turns out I was wrong, at least according to the guys at JSON.org. And I wouldn't exactly call `<[CDATA[]]>` well-suited to binary payloads, not least because you have to convert them to base64 first. But I'll let that one slide.
  • (disco) in reply to RaceProUK

    Am I missing something, or is <[CDATA[]]> (one of the ugliest markup elements in the world) completely unnecessary when you can just put a string value?

    <binarydata>
  <[CDATA[base64]]>
</binarydata>

    vs

    {
  "binarydata": "base64"
}
  • (disco)

    JSON JSON JSON JSON JSON JSON! (I found a WTF about JSON!)

  • (disco) in reply to hungrier
    hungrier:
    Am I missing something, or is `<[CDATA[]]>` (one of the ugliest markup elements in the world) completely unnecessary when you can just put a string value?

    Hmm... chances are slim, but:

    <binarydata>
    <[CDATA[Uh-oh! There's a <tag> in here! Let's close the </tag>!]]>
<binarydata>

    and

    <binarydata>
    Uh-oh! There's a <tag> in here! Let's close the </tag>!
<binarydata>

    aren't the same XML document :stuck_out_tongue_winking_eye:

  • (disco) in reply to RaceProUK

    I mean in the context of JSON. I know why it's there in XML, but why would JSON need it for binary data (or at all)?

  • (disco) in reply to hungrier
    hungrier:
    I mean in the context of JSON. I know why it's there in XML, but why would JSON need it for binary data (or at all)? 
    {
    data: "Hello! I have an unexpected "quoted string" in my binary data! How dreadfully inconvenient!"
}

    fucking rebake the fucking discoshit...

  • (disco) in reply to RaceProUK

    Doesn't CDATA have the same kind of problem?

    <bs><[CDATA[I just love putting symbols in text! ]]> is my favourite!]]></bs>
  • (disco) in reply to hungrier

    Ah, I see what you mean now; forgot about base64 :facepalm:

  • (disco)

    so we're all agreed.... display logic in the data layer is a bad idea?

    :running:

  • (disco) in reply to accalia
    accalia:
    display logic in the data layer is a bad idea
    QFT
  • (disco) in reply to RaceProUK
    RaceProUK:
    QFT

    :blush: thanks!

  • (disco)

    I've seen this kind of thing in the wild. It's what happens when a mediocre DBA decides the developers are dumber than a pack of hammers and decides to put all the logic in the database layer (which they understand) rather than the application code (which they often don't).

    This may not be the worst possible outcome in those cases where the developers are indeed dumber than a pack of hammers.

    The phenomenon can also happen when a DBA is bullied by management into making the database do something it should never have to do, because the DBA has time available and management is pulling out all the stops to complete an already-late project. In those kinds of organizations, idiotic stored procedures are likely to be the least of the problems.

  • (disco) in reply to EatenByAGrue

    Depends exactly how you structure the logic though. Calculations, filtering, and sorting are normally best done as close to the data as possible, though obviously not every time. Data integrity should also be handled at the data layer (obviously!). Business logic should be in the layer above though, and UI logic only in the UI (although you can put stuff in the business logic layer that the UI depends on e.g. flags and stuff).

  • (disco) in reply to RaceProUK
    RaceProUK:
    I kept up with it for a while, but I kinda lost interest over the last year or two. The Stan-Hayley dynamic played itself out surprisingly quickly, you can only do so many crazy-Roger stories before you get sick of them, and Steve and Francine are just not interesting or developed enough as a character to hinge that many stories around. And Klaus is almost completely forgotten.

    I considered it to be the jokes that weren't funny enough for Family Guy, which is saying something.

  • (disco) in reply to RaceProUK

    My comment was not to suggest that this was in any way OK, just to explain the organizational failures are that lead to it. That's the thing about code - it reflects the people and organization who created it.

  • (disco) in reply to RaceProUK
    RaceProUK:
    Depends exactly how you structure the logic though. Calculations, filtering, and sorting are normally best done as close to the data as possible, though obviously not every time. Data integrity should also be handled at the data layer (obviously!).Business logic should be in the layer above though, and UI logic only in the UI (although you can put stuff in the business logic layer that the UI depends on e.g. flags and stuff).

    As a rule -- let your database do your set theory, and your application code do your numeric computation and your data parsing/formatting. PL/SQL is a lousy data parsing tool!

  • (disco) in reply to EatenByAGrue
    EatenByAGrue:
    I've seen this kind of thing in the wild. It's what happens when a mediocre DBA decides the developers are dumber than a pack of hammers and decides to put all the logic in the database layer (which they understand) rather than the application code (which they often don't).

    Also where the DBA doesn't care how good the developers are, just believes the entire application should be done in the database except for some front end web stuff to show the awesome results of his brilliant use of SQL to do the business logic. I have a hammer, this screw is therefore renamed "nail".

    Tarunik - "As a rule -- let your database do your set theory, and your application code do your numeric computation and your data parsing/formatting. PL/SQL is a lousy data parsing tool!"
    Usually I would agree but sometimes when you have to merge in someone else's database for your data mining, doing the data parsing with a SP can be the most efficient approach. One of my last jobs before retiring involved doing an awful lot of this, and the inital approach using Java ran in about 16 hours on my test machines while the SP approach had a runtime of 20 minutes.
  • (disco) in reply to kupfernigk
    kupfernigk:
    Usually I would agree but sometimes when you have to merge in someone else's database for your data mining, doing the data parsing with a SP can be the most efficient approach. One of my last jobs before retiring involved doing an awful lot of this, and the inital approach using Java ran in about 16 hours on my test machines while the SP approach had a runtime of 20 minutes.
    Parsing someone else's database is a whole another can of worms. \*chuckles\* At least you don't have nasty text-blobs masquerading as database fields...but that's a WTF all by itself.

Leave a comment on “JSON at Crystal Lake”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article