The schemas don't need to match



  • We currently generate an XML string representing why-something-happened and store it in the db. Our downstream systems query that table to get the explanation of what happened (stored as a clob containing xml). They use very fragile parsers, where everything is space and case sensitive, so we must be VERY careful not to change the output in any way (yeah, I know).

    There is also a directive for us to reduce the amount of space used to store these explanation strings. We've come up with several alternatives, all of which would require varying amounts of effort with varying rate of disk savings.

    Boss+1 just passed down a directive that we are to create entirely different xml on-the-fly (in response to query-for-explanation) and send it to the downstream systems on-demand.

    Wait, they don't currently know how to parse the new xml, and their existing parsers are extremely fragile...they would need to ...

    That's not a problem. Don't worry, their existing code will work just fine with the new format; it's xml, the schemas don't need to match.

    But...

     



  •  Start speaking to him only in a foreign language, and when he complains that he doesn't speak it, tell him it doesn't matter, you don't both need to speak the same language to communicate. 



  • @hunter9000 said:

     Start speaking to him only in a foreign language, and when he complains that he doesn't speak it, tell him it doesn't matter, you don't both need to speak the same language to communicate. 

     

     

    KAPLAH!



  • @hunter9000 said:

     Start speaking to him only in a foreign language, and when he complains that he doesn't speak it, tell him it doesn't matter, you don't both need to speak the same language to communicate. 

    And of course give the explanation in yet a third language.



  • That's why XML is so awesome. If you used anything else, both the sender and the receiver would have to agree on what data was sent, and how. With XML don't have to do that.



  • @snoofle said:

    We currently generate an XML string representing why-something-happened and store it in the db. Our downstream systems query that table to get the explanation of what happened (stored as a clob containing xml). They use very fragile parsers, where everything is space and case sensitive, so we must be VERY careful not to change the output in any way (yeah, I know).
     

    Erm.. isn't TRWTF hand-rolling your own parser and not just running the XML through some XSLT?

    I understand that changing the XML to conform to a different schema will break some system dependent upon it, but there's scope to use another XSLT to transform the XML from new to old schema so they interoperate until things can change further down the chain.



  • @Cassidy said:

    @snoofle said:

    We currently generate an XML string representing why-something-happened and store it in the db. Our downstream systems query that table to get the explanation of what happened (stored as a clob containing xml). They use very fragile parsers, where everything is space and case sensitive, so we must be VERY careful not to change the output in any way (yeah, I know).
     

    Erm.. isn't TRWTF hand-rolling your own parser and not just running the XML through some XSLT?

    I understand that changing the XML to conform to a different schema will break some system dependent upon it, but there's scope to use another XSLT to transform the XML from new to old schema so they interoperate until things can change further down the chain.

    @snoofle said:
    (yeah, I know)
    Hope that helps.



  • Somehow I knew from the title alone this would be a snoofle thread.


  • ♿ (Parody)

    @Cassidy said:

    Erm.. isn't TRWTF hand-rolling your own parser and not just running the XML through some XSLT?

    What, and add all the bloat from that library?!

    @mott555 said:

    Somehow I knew from the title alone this would be a snoofle thread.

    Me, too, although I thought this was going to be a DB WTF.



  • Taking inspiration from an old Dilbert which I can't manage to find at the moment, if you didn't implement the stupid and kept the XML the same, would boss+1 even know..?



  • @boomzilla said:

    @mott555 said:
    Somehow I knew from the title alone this would be a snoofle thread.

    Me, too, although I thought this was going to be a DB WTF.

    Oh, it is... somewhere down the line.



  • @All

    - Speak in foreign language: don't know any well enough to pull that off

    - Would B+1 notice if I didn't change the xml: No, but my boss would and he's hopelessly honest

    - Thought this would be a DB wtf: The flip side is that they had me duplicate some data (on the fly) to copies of tables so they could run certain reports more efficiently. It was the worst possible solution available given the time constraints. The solution was SUPPOSED to be an interim one. In spite of my warnings that these things tend to set in stone, they deployed it this past weekend. Today, they discovered that the DBAs forgot to partition the duplicate tables (really!), and already there are the beginnings of performance issues. Whoops. So they came to me, told me about this, and asked: as long as we need to redeploy, can you also duplicate a few more tables, and save a few additional fields...

    So now there is a whole spider web of crap being passed around in the code all the way down to the stored procedures to duplicate data in duplicate tables all because of a forced interim solution to a stupid promise by marketing that was never vetted by IT. But don't worry, it's an INTERIM solution.

    Just to make it interesting, a guy who left the firm today created his own Oracle TYPE which referenced MY Oracle TYPE. The funny thing about TYPEs in Oracle is that they're global, and can't be dropped or replaced while something else is referencing them (imagine that: a DB that tries to keep things sane). Does he just add his new types to my file? No. Does he incorporate my types into his file? No. Does he take all the types and put them in a common file? No. He has his file reference my types, but not the other way around, so when I go to change one of my types today (to handle the above-referenced extra crap to duplicate), the system won't free the type so that I can recreate it with the extra fields... Thanks SO much, Dude!



  • You have a cluebat.

    As an interim solution, perhaps wielding it until the walls are dripping with spattered moron?



  • @flabdablet said:

    spattered moron?

    I hear that's good with mango



  • @snoofle said:

    - Speak in foreign language: don't know any well enough to pull that off
     

    Java. It'll be foriegn to them. Just enough technobabble to prove the point.

    @snoofle said:

    The flip side is that they had me duplicate some data (on the fly) to copies of tables so they could run certain reports more efficiently

    Didn't they just sack the last guy that did this?

     @snoofle said:

    all because of a forced interim solution to a stupid promise by marketing that was never vetted by IT

    Anyone currently performing a cost analysis of that promise? What's the figure looking like so far?

    @snoofle said:

    The funny thing about TYPEs in Oracle is that they're global, and can't be dropped or replaced while something else is referencing them

    I thought there was some RESTRICT REFERENCES clause that prevented someone adding an unauthorised reference. I know there is with PK/FK constraints.

    I guess the bigger picture is:

    • lack of preventative measures to forbid the reference
    • lack of documentation/configuration management that alerted you the reference had been made

  • Discourse touched me in a no-no place

    @Cassidy said:

    @snoofle said:

    The flip side is that they had me duplicate some data (on the fly) to copies of tables so they could run certain reports more efficiently

    Didn't they just sack the last guy that did this?

    Don't think so - I got the impression he copied the tables then started updating the copies rather than the original tables.



  • @SteamBoat said:

    KAPLAH!

    Is this the acronym for "Krapped All my Pants Laughing Aloud"?



  • @PJH said:

    Don't think so - I got the impression he copied the tables then started updating the copies rather than the original tables.
     

    <pedant>

    Similar end result, no?

    • The other guy forked the data and updated his copies, meaning snoofle's reports were running against stale data.
    • snoofle's forking the data to snapshot tables and running reports against those, meaning data's still being updated elsewhere and snoofle's reports are running against (slightly) stale data.

    </pedant>

    yeah, realised the other guy didn't get sacked for forking the data, but for being the root cause of customers receiving incorrect reports for 3 months. That and costing the company money when running demonstrations against production DBs. That, and snoof's forking tables according to management imperative, as opposed to "loose cannon" attitude.

    @TGV said:

    Is this the acronym for "Krapped All my Pants Laughing Aloud"?
     

    Keep All Programmers Locked Away in Hell. Or something.


Log in to reply