So if sending mail fails with YouGotHiredException exception, you'll get hired. Hope sending mail fails!
Airhead
@Airhead
Best posts made by Airhead
Latest posts made by Airhead
-
RE: Possible WTF: YouGotHiredException?
-
RE: Stored procedure round-a-bout
@b_redeker said:
@Airhead said:
CONVERT(varchar(8), [FirstAction], 112)
This bit bugged me a bit, until I just remembered what it was: this converts the date to probably yyyymmdd, right?
I just need to warn you, down that road madness lies. Having been in a huge y2k project ages ago, I've seen so many crap that stemmed from people treating dates as strings (or numbers, or almost any data type besides proper good old dates) that I'm still a bit over sensitive to this. I imagine this sproc feeds some object in the application that converts 20100420 back to a date, which works fine until you get to a system with different date settings, or...
</rant>
Having said that, I also seem to remember it's a bitch getting SQL server to treat datetime as just a date.
That said, I actually don't even know why it's converted to yyyymmdd. That was a minor wtf for me, since everywhere else we're using yyyy-mm-dd or as dates. Anywho, it's sproc is executed by PHP (let me quess, another wtf) which draws some charts. I really have to check why it's not retrieved as a date.
-
Stored procedure round-a-bout
One of our products is a build-a-site-for-yourself type of product and we do track each and every visit for our clients. Time used to gather data about visits was just groving and groving so I had to find out what was the problem.
The problem lies in this piece of stored procedure:
DECLARE PageCursor CURSOR FOR
SELECT
CONVERT(varchar(8), [FirstAction], 112)
FROM
[Visits]
WHERE
[SiteId] = @SiteId
AND
(
[Visits].[IsReturning] = 0
OR
@GetAll = 1
)
GROUP BY
CONVERT(varchar(8), [FirstAction], 112)
DECLARE @FirstAction varchar(8), @Hits int
DECLARE @ReturnTable table(FirstAction varchar(8), Hits int)
OPEN PageCursor
FETCH NEXT FROM PageCursor
INTO @FirstAction
WHILE @@FETCH_STATUS = 0
BEGIN
SET @Hits = (SELECT count([FirstAction]) FROM [Visits]
WHERE [SiteId] = @SiteId AND ([Visits].[IsReturning] = 0 OR @GetAll = 1)
AND CONVERT(varchar(8), [FirstAction], 112) = @FirstAction)
INSERT INTO @ReturnTable VALUES (@FirstAction, @Hits)
FETCH NEXT FROM PageCursor
INTO @FirstAction
END
CLOSE PageCursor
DEALLOCATE PageCursor
SELECT * FROM @ReturnTable
I cut execution time from about a minute to less than a second by counting hits with "COUNT(1) AS Hits" instead of looping results. -
RE: C++ compiler does not understand comments (yet?)
I wouldn't call this a WTF but an honest error-by-forgetting-to-add-something. And the comments seem to tell pretty much what is happening here so even I understood what he was trying to accomplish.
-
RE: To take a screenshot in Mac OS, use Command+Shift+3
@random.next said:
While we’re at it, why not speak about CAPS lock? At least it won’t start a flamewar, as it’s not OS-specific.
USING CRUISE CONTROL FOR COOL CAUSES ALL KINDS OF WARS IN THE INTERNETS!
-
How to fetch one row from database
I found this lovely function in our code base. I just love how the while loop is beeing used. Maybe it's expecting a lot of rows, but the function's name and the binding of @ItemId somehow tells me that there should only be one result.
The code has been anonymized a little.
<?php
public function GetItemFromDb($ItemId)
{
global $DbConn;
$Conn = $DbConn->GetConnection();
$Conn->Init('GetItem');
$Conn->Bind('@ItemId', $ItemId);
$Conn->Exec();
$item = false;
$SettingsSet = false;
while ($Conn->Next())
{
if (!$SettingsSet)
{
$this->ItemId = $Conn->res['ItemId'];
/* Removed some $this->{value} get some value */
$SettingsSet = true;
}
$item = new Item();
$item->SetValues($Conn->res);
}
return $item;
}
?> -
RE: Mundane Web app WTF
@Carnildo said:
The way I see it, a good primary key is both 1) unique, and 2) invariant. An email address is indeed unique, but it isn't invariant: people change their email addresses all the time.
Primary keys are changeable. We do update primary keys when ever needed and that hasn't yet caused problems. Ofcourse that has to be noted in all database designs and it causes a possible point for failure - meaning if database administrator does not take care about ON UPDATE.
-
RE: Mundane Web app WTF
@morbiuswilters said:
@Airhead said:
@sprained said:
- records with relations to user table don't use integer prima\ry key as foreign key, but instead user's full name.
This is not a WTF because of lack of integers, but because no full name is unique. There can be plenty of John Does around.
I personally like to use something else but integers as primary keys. I think it shows lack of database desing, if you need to run integers on every table just to identify rows. That way you end up with views like this:
User | SomeOtherData
------------------------------
1 3
2 8
8 2What does that tell you? Nothing.
I think natural primary keys oftentimes show a lack of database design. You end up with all sorts of problems, including performance penalties, the problem of duplicates and the difficulty of updating keys when part of the primary key of a record changes. It might be sensible in theory, but in practice natural primary keys are lame.
I fail to see the problem with duplicates - you just need to set the "do not allow duplicates" bit on. And the updating of the primary key is done automatically by "on change".
I've been using natural primary keys quite some time with MSSQL and I have no problem with them. I agree something like full name is a bad choise for primary key, but email, for example, cannot be duplicate and if two ppl choose to use one email address, that is their loss. But obviously, I do not use natural primary keys for stuff like orders because there is no guaranteed-to-be-unique information.
- records with relations to user table don't use integer prima\ry key as foreign key, but instead user's full name.
-
RE: Mundane Web app WTF
@Carnildo said:
@tgape said:
@sprained said:
User's full name. What do you do when Jane Doe in Accounting gets married?- records with relations to user table don't use integer primary key as foreign key, but instead user's full name.
Depending on the database, that may have a surprisingly low performance impact. Using usernames might be more meaningful to administrators of the system. Assuming that usernames aren't 50 character random strings or something crazy like that, it's possible this isn't a WTF.
Then you obviously change the primary key for the current user and your well designed database updates the primary key to related tables.
-
RE: Mundane Web app WTF
@sprained said:
- records with relations to user table don't use integer prima\ry key as foreign key, but instead user's full name.
This is not a WTF because of lack of integers, but because no full name is unique. There can be plenty of John Does around.
I personally like to use something else but integers as primary keys. I think it shows lack of database desing, if you need to run integers on every table just to identify rows. That way you end up with views like this:
User | SomeOtherData
------------------------------
1 3
2 8
8 2What does that tell you? Nothing.
- records with relations to user table don't use integer prima\ry key as foreign key, but instead user's full name.