My Daily WTF of today
-
I just came here to say that you should privately document your work schedule. When shit hits the fan you have external proof of how much you worked.
One easy way is to send a mail to a private address when you enter and when you leave work. Mails are good evidence due to their Received lines which are hard to forge, especially if you keep the mails with a third party.
-
Don't forget to send the mail with your mobile device at the appropriate time should you happen to be running a bit late (or wish to leave a bit early).
-
Also, don't forget to quit that fucking job and find a real company that doesn't abuse it's workers.
-
@Lorne_Kates said:
Also, don't forget to quit that fucking job and find a real company that doesn't abuse it's workers.
but do remember not to do that too soon. job hunting sucks enough as it is, job hunting while unemployed SUCKS DONKEY BALLS!
-
but do remember not to do that too soon. job hunting sucks enough as it is, job hunting while unemployed SUCKS DONKEY BALLS!
Given that @ascendant keeps saying he doesn't have enough food for lunch, sucking donkey balls may actually be a good source of nutrition for him.
-
Now I see your profile picture may be a man facepalming.
-
Now I see your profile picture may be a man facepalming.
-
@Lorne_Kates said:
The goal is to be diplomatic, non-antogistic
Who are you and what have you done with @Lorne_Kates?The only reference I can find to antogistic that may not be a typo is, "Clozapine's antipsychotic action is likely mediated through a combination of antogistic effects at D2 receptors in the mesolimbic pathway and 5-HT2A receptors ..."
So that sounds about right.
-
-
I'm surprised myself that I didn't realise this before but I just did.
This 2 million dollar project uses varchar type columns to store dates.
I can safely insert "Putin is my best friend" in any date(varchar type) columns.
I have to get any damn "date string" which looks like "20160126", substring(0,4) to get the year, and put them back as "2016-01-26" to display to the users.
FML
Oh btw, did I tell you that we use
SELECT MAX(ID) +1
to get the next sequence value?
-
I'm surprised myself that I didn't realise this before but I just did.
This 2 million dollar project uses varchar type columns to store dates.
I can safely insert "Putin is my best friend" in any date(varchar type) columns.
I have to get any damn "date string" which looks like "20160126", substring(0,4) to get the year, and put them back as "2016-01-26" to display to the users.
FML
Oh btw, did I tell you that we use
SELECT MAX(ID) +1
to get the next sequence value?So do you end up with "20160199"?
-
So do you end up with "20160199"?
Nuh I was talking about two different WTF.
One is using VARCHAR to store datetime.
The other is using SELECT MAX(ID)+1 for getting a sequence value.Both I think are pretty WTF, especially when it's not homework but commercial multi million dollar projects.
-
That's what people do when they need something like identity column and they use transaction and they don't want "gaps" between the numbers. (When transaction got rollbacked, it skips the ID already allocated for the next record)
-
Interesting.
It seems to me then, people just recommend that I use a sequence object, almost always, without saying that there possibly is a good reason to use
SELECT MAX(ID)+1
.I wonder why.
Any drawbacks with that (MAX()+1 in transaction) method?
-
There are multiple reasons... The most important one is it's easy to .
To use this approach, you need to add unique index to that column to ensure you won't get duplicate key, then try to use a loop to insert the row repetitively (with ID + 1 each time) until it success if the error message contains specific words for unique key violation (which could cause you trouble if the system will use SQL server of other language version).
Using auto-increment feature will make your life much easier.
-
To use this approach, you need to add unique index to that column to ensure you won't get duplicate key, then try to use a loop to insert the row repetitively (with ID + 1 each time) until it success if the error message contains specific words for unique key violation (which could cause you trouble if the system will use SQL server of other language version).
Yeah that sounds quite icky.
-
Oh btw, did I tell you that we use SELECT MAX(ID) +1 to get the next sequence value?
Please tell me you're buying a clue bat.
-
transaction
You think @ascendant's "senior software guru wizards" even KNOW what a Transaction is? You're cute.
-
which could cause you trouble if the system will use SQL server of other language version
It won't if you just check for
ORA-00001
.I'll show myself out.
-
-
@Ascendant : Have you thought of using your company access to plant evidence that your superiors are conspiring with North Korea? That way you can have them arrested and executed. The next boss might know how to pay his employees on time.
-
That's what people do when they need something like identity column and they use transaction and they don't want "gaps" between the numbers. (When transaction got rollbacked, it skips the ID already allocated for the next record)
That is the dumbest thing I've ever heard.
-
That is the dumbest thing I've ever heard.
- Bitcoin
- Year of the Linux desktop
- Windows 8
- Discourse
- All my email is unclassified
-
-
@boomzilla said:
Year of the Linux desktop
How many of those have we had in the last decade?
Has to have been at least 10, right?
-
I've heard every year since 2000 be declared as the Year of Linux on the Desktop.
-
Agreed, but in my first job, I was scolded by my boss for not following this.
Since we used the ID field as the order number, having "gaps" in order number means the people processing invoice cannot conveniently see whether all invoice has been collected. (When we send goods to customers, sometime the people will also be tasked to collect money on delivery - the Cash On Delivery thing. So in the end of the day, our accountants will count and see whether will the invoice copies are returned)
-
there possibly is a good reason to use SELECT MAX(ID)+1.
Eww, nasty for all the aforementioned reasons... though I had to use this once.
The story was, every pair of records inserted into the table had to have a sequential ID. So an insert trigger would have to check MAX(ID), and see if there's one or two records with that - if there are two, it got the next number, if there's one, it gets the paired number.
First time I felt honestly dirty writing code. Told the guy who ended up maintaining it "if you can fix it, please do, I'm out of ideas".
-
If you're inserting a pair of records that should have the same ID, insert them together using the same client function/stored proc in the same TXN. If they need subsequent IDs, do the exact same thing, but set the increment of your sequence to 2.
-
If you're inserting a pair of records that should have the same ID, insert them together using the same client function/stored proc in the same TXN.
I think the problem was that they didn't have to be inserted at the same time, but I don't remember now.
-
I think the problem was that they didn't have to be inserted at the same time, but I don't remember now.
I can absolutely positively 100% guarantee that if you're using the ID to do anything except identify a record, it's a . It will always, ALWAYS bit you in the ass.
This happens every time. This JUST happened this week with a client:
This item has two categories, but the primary category isn't showing up in the breadcrumbs
Just make sure the right category as the "Is Primary Category" field checked
We customized the system so it doesn't use that, it was confusing. The first category should be the primary one
??? Okay. Then just put the categories in the order you want in the category manager.
We did, and it still doesn't work.
Did you click "Re sequence Categories", to force the system to re-number the "Sequence Order" field.
Yes. But we insisted, long ago, that everything sort by Category ID, the primary key.
We should change that, but it'll be a billable change request...
And why were they doing that? Because looking at their initial data years ago-- they entered the categories in one by one, in a single-user session. So of course they were in the right order. Now years later, they happened to do something-- like manually inserting the categories in the reverse order, or inserting a new "Primary Category" after the fact, or something. And rather than using any of the multiple SMART sorting ways built into the system, they came up with their own.
And of course, it doesn't work. Because:
#IF YOU USE AN IDENTIFICATION FIELD FOR ANYTHING OTHER THAN IDENTIFICATION, IT IS A WtF AND WILL 100% BREAK AT SOME POINT
-
Yeah, yeah, it had a usual surrogate key and an additional "pair ID" or something. Jeesh, no need to
<h1>
at me like that.How that database looked before I got to it, though... well, let's say that a 7-column primary key that's there only because the data so far just happened to have those values be unique is not fun to deal with at all.
-
I've heard every year since 2000 be declared as the Year of Linux on the Desktop.
As far as I can tell, that's become an inside joke. Similar to how people say "Thanks, Obama!" or "What now, Captain? It'll take cannonballs to get out of here alive."
-
Since we used the ID field as the order number,
IDs are IDs. If you're using them for anything other than IDs, then your database was designed by a dummy idiot moron jerk.
-
Or just add a foreign key column so you can link the records together at any time, not just creation time.
-
@Lorne_Kates said:
IF YOU USE AN IDENTIFICATION FIELD FOR ANYTHING OTHER THAN IDENTIFICATION, IT IS A WtF AND WILL 100% BREAK AT SOME POINT
I said it better. Nyah.
-
Yeah, that's more along the lines of "In the extremely unlikely case you ever end up in a situation where one of those is a reasonable thing to do,
MAX(ID)
is still not the way to do it.
-
@Lorne_Kates said:
IF YOU USE AN IDENTIFICATION FIELD FOR ANYTHING OTHER THAN IDENTIFICATION, IT IS A WtF AND WILL 100% BREAK AT SOME POINT
I said it better. Nyah.
I said it first. Hayn.
-
IDs are IDs. If you're using them for anything other than IDs, then your database was designed by a dummy idiot moron jerk.
First Rule Of Anything Design: If both @Lorne_Kates and @Blakeyrat can agree that your design is bad, then your design is epically bad and you should never work in the industry again.
Corollary to First Rule Of Anything Design: If that design is UI/UX, then you have created literally the worst thing to ever assault a human eyeball. Consider traveling back in time and murdering your ancestors, for you have shamed them beyond repair and it's best if neither you nor they ever existed.
-
The story was, every pair of records inserted into the table had to have a sequential ID.
Why would you even do that?
Why not just use an ordinary sequential ID and then use ID/2 to get the pairs?
-
Why not
Read further. It was explained than the record pair need not be inserted at the same time.
-
This starts sounding contrived. Anyway you hold on to the ID.
-
@Lorne_Kates said:
both @Lorne_Kates and @Blakeyrat can agree
I'm not sure I want to live in that world.
-
Btw, the website was originally written by an advertising company (i.e.: not even a software vendor) as part of their startup package in PHP, just later ported to ASP.NET v1.1.
-
Yeah, doesn't 1NF say that the records should be unordered?
There's no top-to-bottom ordering to the rows.
-
Read further. It was explained than the record pair need not be inserted at the same time.
A separate Pair or Group ID, might have been better?
-
-
Doesn't matter. Integer division by 2 on an ordinary auto-increment integer ID field would give every pair of 2 rows a unique pair ID, regardless of whether they were added both at once or separately at two separate times.
The real is that the order in which the rows were entered into the data set is a logically-significant part of the data. That's majorly .