GetID, or "SQL-based version control"!



  • Poking through some offshored VB.NET code to fix a few bugs, I found this gem:

    qry = "select max(b.idimage) from image a, image b where a.image_name=b.image_name and a.idimage=" & imageid

     It was inside a function called "getID"...

    So let me get this straight, this function, you pass in an ID... and it gives you an ID back... what exactly is the point of that anyway? The only use I could imagine is that since it calls a max function on the second instance of the image table, that it's some sort of hacky "version control" system - you put in an ID, it gives you the newest item with the same name!



  • You may laugh, but I have seen SQL-based version control for source code before.  Turns out the dev thought CVS and SVN were too confusing, so he just inserted a row containing the filename in one column, the entire file in a TEXT column and an incrementing version number in a third.  To get the latest version, he just selected MAX(version_number) WHERE filename = "foo".



  • The sad part is that I think that some version control software actually uses a database for the file storage.



  • @henke37 said:

    The sad part is that I think that some version control software actually uses a database for the file storage.

    Subversion does. Well, FSFS has been the default for quite a while, but the Berkley DB option is still available.



  • Seeing as how filesystems are by their very nature databases, I would think that all RCS are database-oriented.

    You have a set of objects, and some relation of those objects one to another, and a set of operations on those objects.

    Sounds like a database to me.



  • @henke37 said:

    The sad part is that I think that some version control software actually uses a database for the file storage.

    Using a database for revision control is not a WTF (and if done properly is actually a smart idea).


  • Garbage Person

    @Heron said:

    Using a database for revision control is not a WTF (and if done properly is actually a smart idea).
     

    I actually have an SVN hook on commit that keeps track of the repository, revisions, files changed per revision and optionally, depending on whether the project is flagged for it, an actual diff for each file at each revision (for big changes a text field actually isn't big enough - the damn thing had to be bigtext). This information then gets cross-referenced with the databases behind our bugtrackers, and builds a series of references based on the commit messages and any comment text in the diff itself. This is all then tied into the time and billing system - so we instantly know everything productive that a given user did while they were working.

     Would've saved me some effort if SVN could be told "Here, use this database server"



  • @Weng said:

    I actually have an SVN hook on commit that keeps track of the repository, revisions, files changed per revision and optionally, depending on whether the project is flagged for it, an actual diff for each file at each revision (for big changes a text field actually isn't big enough - the damn thing had to be bigtext).

    Dear God, why the diff?  Why not just use SVN's built-in revision comparison tools?  Why create an entire copy of the SVN repo and risk one being out of sync with the other?



  • @morbiuswilters said:

    You may laugh, but I have seen SQL-based version control for source code before.  Turns out the dev thought CVS and SVN were too confusing, so he just inserted a row containing the filename in one column, the entire file in a TEXT column and an incrementing version number in a third.  To get the latest version, he just selected MAX(version_number) WHERE filename = "foo".
    Why is this not an OP? Better yet, did you hurt him or is he still out there doing this crap?



  • @DOA said:

    @morbiuswilters said:

    You may laugh, but I have seen SQL-based version control for source code before.  Turns out the dev thought CVS and SVN were too confusing, so he just inserted a row containing the filename in one column, the entire file in a TEXT column and an incrementing version number in a third.  To get the latest version, he just selected MAX(version_number) WHERE filename = "foo".
    Why is this not an OP? Better yet, did you hurt him or is he still out there doing this crap?

    I just really love threadjacking.

     

    I've got so many WTFs that if I were to post them all it would take months.  This particular dev is still doing this kind of stuff, but I think he's mostly retired by now.  Unfortunately, most of the horrible devs I've known are still active in some capacity.  One of the worst works for $LARGE_SEARCH_ENGINE.



  • @morbiuswilters said:

    One of the worst works for $LARGE_SEARCH_ENGINE.
    He works for Baidu?



  • @morbiuswilters said:

    I've got so many WTFs that if I were to post them all it would take months.  This particular dev is still doing this kind of stuff, but I think he's mostly retired by now.  Unfortunately, most of the horrible devs I've known are still active in some capacity.  One of the worst works for $LARGE_SEARCH_ENGINE.
    Well get crackin!



  •  @drachenstern said:

    Seeing as how filesystems are by their very nature databases, I would think that all RCS are database-oriented.

    You have a set of objects, and some relation of those objects one to another, and a set of operations on those objects.

    Sounds like a database to me.

    Ghost of TDWTF Past here, this has already been argued, and you are welcome to rehash it, but keep that discussion in this thread.

    Remind me to get old threads locked before I link them.



  • @bstorer said:

    @morbiuswilters said:
    One of the worst works for $LARGE_SEARCH_ENGINE.
    He works for Baidu?
    No, obviously he meant cuil, the google killer.



  • @belgariontheking said:

    Ghost of TDWTF Past here, this has already been argued, and you are welcome to rehash it, but keep that discussion in this thread.
    Seems like a good idea to me, but it's always a question of definition, no? Like you said, the question of is a filesystem a database is a long-lived argument, so this is not the place for that discussion.

    Also, you should get that old thread locked ;)


  • Garbage Person

    @morbiuswilters said:

    Dear God, why the diff?  Why not just use SVN's built-in revision comparison tools?  Why create an entire copy of the SVN repo and risk one being out of sync with the other?

    Because a fat ugly hard drive with a fat ugly full text index on the diff column makes generating cross-references based on diff content about a million times faster. Disk space is cheap. Real cheap.

     

    And yes, it makes sure it didn't miss a revision (and if it did, it currently alerts a human to schedule a rebuild or catch-up) every time it runs - and if it stopped running altogether, we'd notice rather quickly because it integrates into the system that prints our checks.



  • @Weng said:

    Because a fat ugly hard drive with a fat ugly full text index on the diff column makes generating cross-references based on diff content about a million times faster. Disk space is cheap. Real cheap.
    <joking>

    FAT? NOOOOOO

    FAT baaaadddd, use a journaling system...

    </joking>

    Actually, in this case, I think journaling wouldn't work as effectively, but this is so far OT that it's barely worth anyone replying to... <cue-regulars-to-mock-me>


  • Garbage Person

    Oh right. The word "fat" isn't supposed to be used for large things and people anymore. Obama made that law, right?

    @Weng said:

    Because a obese ugly hard drive with a obese ugly full text index on the diff column makes generating cross-references based on diff content about a million times faster. Disk space is cheap. Real cheap.

    Totally fixed.



  • @Weng said:

    @Weng said:

    Because a horizontally challenged ugly hard drive with a horizontally challenged ugly full
    text index on the diff column makes generating cross-references based
    on diff content about a million times faster. Disk space is cheap. Real
    cheap.

    Totally fixed.

    TRFTFY.



  • @Spectre said:

    @Weng said:

    @Weng said:

    Because a horizontally challenged ugly hard drive with a horizontally challenged ugly full text index on the diff column makes generating cross-references based on diff content about a million times faster. Disk space is cheap. Real cheap.

    Totally fixed.

    TRFTFY.

    That makes me think of penises.  A better phrase might be "gravitationally challenged" or "fast-food-made disaster".  Everything wrong with the world is to blamed on big business and capitalism, not personal responsibility, right?


Log in to reply