• (disco)

    What about disabling constraints during database creation?

    That doesn’t justify blind renaming, though. Java supports reflection so it may be very complicated to know if a method is safe to rename or not.

  • (disco)

    "repair the testing environment." - No version control!?

  • (disco)

    as per Java standards

    Where is this defined? I've never seen something like PEP for Java.

  • (disco)

    Instead of creating tables in the sensible order that they depended on each other, instead, they were being created with invalid foreign key restraints but in perfectly alphabetical order

    Uh, why not just do it the proper way and create the tables first in whatever order you want, and then create the constraints and relationships after all the tables are done?

    Seems a much more sensible way to do it, creation order doesn't matter but process step order does.

  • (disco)

    Kinda seems to defeat the purpose of version control if you can't easily revert commits...

  • (disco) in reply to Eldelshell
    Eldelshell:
    > as per Java standards

    Where is this defined? I've never seen something like PEP for Java.

    Well, it's more a guideline...

    Here's a PDF of the Java Code Conventions (used at Sun back in the day).

  • (disco) in reply to JBert

    Sure, conventions, not standards. Is just stupid.

  • (disco)

    Deleting the backup? Shouldn't that be a fireable offence?

  • (disco) in reply to Jake_Lee
    Jake_Lee:
    "repair the testing environment." - No version control!?

    I think he broke the database... No version control for those.

    (Version control for databases... Sounds like something from the bad ideas thread)

  • (disco)

    The trwtf that this wasn't in version control

    sloosecannon:
    Version control for databases

    The various create table, create procedure scripts can be kept in version control.

  • (disco) in reply to lucas
    lucas:
    The various create table, create procedure scripts can be kept in version control.

    Well yeah. I meant version control for the whole database.

    Upon further review I'm not actually sure that happened. Unless the guy saw "Database error" and immediately thought "Oh, let's delete all the data, that'll fix it!"

  • (disco) in reply to sloosecannon
    sloosecannon:
    I meant version control for the whole database.

    We call these backups.

  • (disco) in reply to sloosecannon
    sloosecannon:
    I think he broke the database... No version control for those.

    No, but you can keep the schema in the repository.

  • (disco)

    Not really a WTF in my opinion. The only wtf is a description, as Purist would care more about microarchitecture, pattern usage, code smell, that sort of thing. A code with underscored names, lowercase constants, capital case variables would hurt eyes for any competent Java developer.

    If the code is not working anymore, the guy should see that in the your CI build status, no? or am I guessing it right and there there is none?...

  • (disco)

    OK, I know I go and do this kind of thing in my personal projects when I'm the only author, but on my company codebase? No way in hell.

  • (disco)

    TRWFT is "as per" when "per" is sufficient.

  • (disco)
    Jane Bailey:
    foreign key reconstraints

    FTFY

    Filed Under: SQL Purist

  • (disco)

    Deleted comments 1-3: Replaced with discussion about paulabean postings per TDWTF standards.

    Deleted comments 8-22: Replaced with bitching about Discourse per TDWTF standards.

  • (disco) in reply to FrostCat
    FrostCat:
    No, but you should keep the schema in the repository.

    FTFY

  • (disco)

    OK, so not testing after each commit is a WTF....but..

    1. Small single focused commits is a good thing.
    2. Standardized code formatting is a good thing. (possible WTF in letting it get out of control - but that is out of scope)
    3. DB Creation script sequencing may be WTF, but it is worst that there was apparently no error checking in the scripts!

    Conclusion, the work illustrated had execution flaws, highlighted underlying problems.

  • (disco) in reply to RichP

    Deleted comments 23-eleventy billion: because i could. replaced with output of markov chains.

  • (disco)

    I think I have worked with this guy. Not as much fun,though, as the one who decided, on a production code base, to refactor everything in accordance with the suggestions made by Netbeans, thus creating thousands of changes with no impact on performance, but a strong adverse impact on readability. Status? Junior programmer, new CS grad. Real world experience nil.

  • (disco)

    I don't see any WTF with the purist. An easy to read codebase does save time. And sometimes when dealing with code, things break. Business as usual. Also, if the "purist" wrote these comments it's an average coder, certainly not a purist.

    Now, several people needing an entire weekend shift to repair a test environment because of a change to a database creation script, that's a proper WTF! Any halfway decent test environment is something that can be created with the click of a button. The test environment can and will be messed up, that's almost the purpose of it's existence. Rollback, click button, done.

  • (disco) in reply to kupfernigk
    kupfernigk:
    suggestions made by Netbeans
    Those are fun; if you have Java 8 lambda in your code, it will offer you to replace with object of anonymous class, which will subsequently offer you to replace with lambda expression.
  • (disco) 
    +---------------------------------------------------------------------+
| Rev 666 | Fired 'purist' as per corporate policy   |
+--------------------------------------------------------------------+
  • (disco) in reply to RichardPrice
    RichardPrice:
    Uh, why not just do it the proper way and create the tables first in whatever order you want, and then create the constraints and relationships after all the tables are done?

    Well, I don't think that is the proper way. I think ideally table creation, for each mainly self contained region of the schema, should start with all the tables that have no foreign keys and then work up, so that the database script can create constraints and relationships close to the affected tables. It is a bit like declaring variables and objects before you use them. Not everybody is visual and some people have difficulty with ERDs.For them it is clearer that you create customers and salespeople before you create sales orders, for instance. With a complex database (or a schema with several linked databases depending on your RDBMS) it is useful to be able to explore a restricted region of the schema without having to jump around a document that may be hundreds of kilobytes long. I've had to disentangle enough databases in my time for data mining that I've learned to appreciate when people take a little trouble over this (and also to be suitably annoyed with random scatter database scripts.)

  • (disco) in reply to kupfernigk
    kupfernigk:
    hundreds of kilobytes long

    Yeah, that could be difficult... [image]

    I've seen database creation scripts well into the tens of megabytes

  • (disco) in reply to kupfernigk

    Well, I don't think that is the proper way. I think ideally table creation, for each mainly self contained region of the schema, should start with all the tables that have no foreign keys and then work up, so that the database script can create constraints and relationships close to the affected tables. It is a bit like declaring variables and objects before you use them.

    Well, thats exactly what I suggest doing in my comment - tables first, then everything else afterward.

    Its how I write my SQL scripts - first the database, then the tables, then the constraints, then the relationships, then the seed data.

    Not sure where you think your suggestion differs from mine...

  • (disco) in reply to RichardPrice
    RichardPrice:
    Not sure where you think your suggestion differs from mine...

    He's creating constraints before he creates all of the tables.

  • (disco) in reply to Jaloopa

    the proper way to create and maintain those files is (AFAIAC) >DB_CNAME.create.sql mysqldump --no-data --triggers --events DB_NAME

  • (disco) in reply to boomzilla

    Ahh, in that case, his approach sucks :smile:

  • (disco) in reply to Eldelshell
    Eldelshell:
    Where is this defined?
    [image]
  • (disco) in reply to Jaloopa
    Jaloopa:
    've seen database creation scripts well into the tens of megabytes
    RichardPrice:
    Ahh, in that case, his approach sucks

    So, yours is bigger than mine. Was it intended in any way to be human readable? If you use (say) SQL Studio to design your database and use its tools to dump the database creator then any discussion of order is arbitrary, it isn't intended to be human readable. If your database creation script is of reasonable size and going to be reviewed by an anal retentive crusty DBA who is neurotic about security, table size and data size, being human readable is essential if you ever want it implemented. And they exist in surprising numbers, and your sales department will not love you if the DBA keeps delaying by demanding explanations.

  • (disco) in reply to accalia
    accalia:
    the proper way to create and maintain those files is (AFAIAC) >DB_CNAME.create.sql mysqldump --no-data --triggers --events DB_NAME

    I tried this on an SQL Server database and a DB2 database. Why doesn't it work? What am I doing wrong?

  • (disco) in reply to kupfernigk

    Translate as appropriate for different dbms.

  • (disco) in reply to RichardPrice
    RichardPrice:
    Ahh, in that case, his approach sucks :smile:

    You both suck. His has ordering problems and yours means I can't see the definition of a table in one place.

    I HATE YOU ALL

  • (disco)

    I worked with a guy who couldn't stand C++ style "//" comments. He'd go through all the code manually converting them all to C-style. It was a C++ project.

    // Hi Gary!

    /*

    • Please refrain from inserting frivolous comments in the code base. */
  • (disco) in reply to nightware

    I worked with a guy who couldn't stand C++ style "//" comments. He'd go through all the code manually converting them all to C-style. It was a C++ project.

    The funny thing is that C has had "C++ style" comments for over 15 years, so now they are also "C style" comments.

  • (disco) in reply to christop
    christop:
    for over 15 years

    This was almost 20 years ago, an old story... I think we could use // in C even then, maybe with a compiler flag.

  • (disco) in reply to boomzilla
    boomzilla:
    You both suck. His has ordering problems and yours means I can't see the definition of a table in one place.

    Don't some databases have a way to disable constraints so you can do:

    disable fk constraints
install everything in readable order
enable fk constraints <-- here, errors get thrown if something was set up incorrectly

    ...what? Of course I'm not going to bother looking it up myself...

  • (disco) in reply to Bort
    Bort:
    Don't some databases have a way to disable constraints so you can do:

    Yes, good point.

  • (disco) in reply to Bort
    Bort:
    Don't some databases have a way to disable constraints so you can do:

    yes. because it can be a pain in the ass to define a circular FK relationship without that sort of thing.

    if you can't temproarily remove constraints you have to issue an ALTER TABLE statement later.... and remember about it, to get the relationships right.

  • (disco) in reply to accalia
    accalia:
    Deleted comments 23-eleventy billion: because i could. replaced with output of markov chainsTranslatorBot.
    FTFY ;)

    <No, I'm not summoning it; there's no need. Is there?

  • (disco) in reply to RaceProUK
    RaceProUK:
    FTFY

    frack! not fast enough to catch proof of your hanzo edit!

  • (disco) in reply to Jaloopa
    Jaloopa:
    I've seen database creation scripts well into the tens of megabytes

    I find it hard to conceive of that many relations being meaningful to anyone with a normal short-term memory. What are you doing with all that? Or were you mixing DML (which can easily get long-winded) with the DDL in order to populate some key tables?

  • (disco)

    Nobody posted go fmt without any context yet?

    EDIT: @ben_lubar, am I Doing This Right™?

  • (disco) in reply to FrostCat
    FrostCat:
    No, but you can keep the schema in the repository.

    The schema is built incrementally over many releases, so you can't really keep it in the repository. You can keep the SQL that was used to build it at the time(s), but that's a different thing.

    Our repository has views, packages, functions, etc. in it. Anything that is idempotent, which basically means anything that starts "CREATE OR REPLACE". Table creation or modification is not idempotent, so it only lives until the next release, when it is deleted.

  • (disco) in reply to powerlord
    powerlord:
    but on my company codebase? No way in hell.

    Because you don't care about the quality of your company codebase?

  • (disco) in reply to RichardPrice
    RichardPrice:
    Uh, why not just do it the proper way and create the tables first in whatever order you want, and then create the constraints and relationships after all the tables are done?

    Because the proper way is to create the tables and constraints together. The tables aren't done without the constraints, which is why they're included in the create table statement. You're trying to half-create the tables, then come back and fix them up with alter table statements. Why not do it right the first time?

  • (disco)

    This reminds me of someone who used to insist that stored procedure parameter names be @camelCased. Never mind that the default collation is case-insensitive, or that there were already 100+ procs using a different convention...

Leave a comment on “The Java Purist”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article