Comment On This Should Work Just Fine

future planning...

brilliant.

(in best cave man voice): ugh, me no like round wheel, me like square wheel.

Truly, the mind boggles.

In tech it's usually the case that if something feels stupid, it probably is, and if it seems like there ought to be a better way, there probably is.  Failure to realize these situations, or failure to be able to find the solution (come on, a DB without a sequence? wtf) is the sign of a bad technologist.

tercero!

Some people should be legally barred from using computer technology.

I'm beginning to think all registered users need an auto-reply to all post feature that reposts the same thing over and over on every thread.

Very nice.  A good, solid, old-school WTF. 

 haha nice one :D

Ok, I have an honest question.

I use a method like this because I need to know the ID number before I write something to the database (like, to create a link to the new object in several tables).  So I generate a random ID, check to make sure it isn't already in use, and return it.

I know MSSQL has an auto-increment option, but how would I implement a non-WTF solution that returns the ID so I can use it?

Anonymous:

Ok, I have an honest question.

I use a method like this because I need to know the ID number before I write something to the database (like, to create a link to the new object in several tables).  So I generate a random ID, check to make sure it isn't already in use, and return it.

I know MSSQL has an auto-increment option, but how would I implement a non-WTF solution that returns the ID so I can use it?

Use UUID/GUID.

There's so many OTHER WTFs too...

1) why just build up 1 digit at a time?  Why not all 6 (or 9) at once?

2) What's stopping someone else from getting the same random number(s) before the new ID is used?

3) Why not do this in the DB using RAND or it's equivalent and thus only use one DB call

 

*brain imploding*

To be clear, you don't need the SELECT ahead of time to test for availability.  So you can construct the entire object graph in memory and pump it all down to the DB without having to get back what the ID is actually going to be like you do with IDENTITY, SEQUENCE, etc.

I admit that I did have to invent a method of assigning transaction ID's before.  (Older versions of FoxPro didn't have any autoinc fields.)

But when I did it, I made it so that there were around 14 quintillion possible id's.  And I only expected a few hundred new ones per day.

(Yes, yes, everyone can start in with the "FoxPro is the *real* WTF" comments.  I'm sure that Nostradamus even had a quatrain predicting those.)

If he starts running out of Guids I can sell him some... special price, $15 for 10!

Anonymous:

Ok, I have an honest question.

I use a method like this because I need to know the ID number before I write something to the database (like, to create a link to the new object in several tables).  So I generate a random ID, check to make sure it isn't already in use, and return it.

I know MSSQL has an auto-increment option, but how would I implement a non-WTF solution that returns the ID so I can use it?

SELECT @output= @@IDENTITY

or

SELECT @output = SCOPE_IDENTITY()

Identity columns and @@Identity

You could try to get the highest ID (with MAX()) and simply and 1 to that number and use it as your ID.

DECLARE @CustID integer
INSERT Customer(Name,Age) VALUES('WTF', 42)
SELECT @CustID = @@IDENTITY
INSERT Orders(CustomerID,Amount) VALUES( @CustID, 69 )

Anonymous:

You could try to get the highest ID (with MAX()) and simply and 1 to that number and use it as your ID.

Not threadsafe.  The WTF isn't either, but not a good solution

Here's the solution for MS-SQL:

sql = "SET NOCOUNT ON;
INSERT INTO foo (bar) VALUES ('whatever');
SELECT @@IDENTITY FROM foo;"

your recordset will contain the ID of the record you just inserted

 

# and give the added
# benefit of being a random order 

perhaps he should have added a b_tree balancer 

Anonymous:

Ok, I have an honest question.

I use a method like this because I need to know the ID number before I write something to the database (like, to create a link to the new object in several tables).  So I generate a random ID, check to make sure it isn't already in use, and return it.

I know MSSQL has an auto-increment option, but how would I implement a non-WTF solution that returns the ID so I can use it?

you should do
select my_seq.nextval
into :foo
from dual;

then do all your inserts into the child tables using the :foo var

then do the final insert into the parent table using the :foo var

REMEMBER FOLKS:

Every time you program like that God kills a kitten.

Anonymous:

If he starts running out of Guids I can sell him some... special price, $15 for 10!

Is that ten factorial GUIDs for $10, or are you just excited about selling GUIDs for $1.50 each?

Sincerely,

Gene Wirchenko

Anonymous:

Anonymous:

You could try to get the highest ID (with MAX()) and simply and 1 to that number and use it as your ID.

Not threadsafe.  The WTF isn't either, but not a good solution

question: is it thread safe if you do a nested SQL? something like

insert into foo (
  select (max(id)+1), 'first name', 'last name', '12345'
  from foo
)

i think it is.

Anonymous:

Ok, I have an honest question.

I use a method like this because I need to know the ID number before I write something to the database (like, to create a link to the new object in several tables).  So I generate a random ID, check to make sure it isn't already in use, and return it.

I know MSSQL has an auto-increment option, but how would I implement a non-WTF solution that returns the ID so I can use it?

Use a transaction. You can insert the row, then should be able to read out the used id and create more inserts with that id and they will all happen at once from an onlooker.

Anonymous:

You could try to get the highest ID (with MAX()) and simply and 1 to that number and use it as your ID.

Really bad if you delete some rows. MAX ID will be 10 and auto_increment will be 15.

Anonymous:

You could try to get the highest ID (with MAX()) and simply and 1 to that number and use it as your ID.

That's another WTF :D:D:D

Awesome.  I like that the guy didn't actually solve the underlying
problem, just kind of swept it a little further under the rug.



I hope he bragged later about fixing the whole app with "1 keystroke!".



Waiting for someone to say that the Real WTF is that the system was written in Perl...

What I did on a system we were converting from Interbase to MSSQL was create a generators table, and then I wrote a stored procedure to first update the value in the generators table and then return it to the caller. I don't have the code in front of me, but it was something like:

update generators
set @NewID = genvalue = genvalue + 1

Where NewID was an output variable. We tested this with multiple people concurrently pulling values, and did not get any duplicates.

Of course, where possible, I used MSSQL's native identity stuff.

Anonymous:

I'm beginning to think all registered users need an auto-reply to all post feature that reposts the same thing over and over on every thread.

I have noticed a similarly distressing lack of originality in the replies. Yes, we all know that some of you think others should be barred from programming. Yes, we all know that the goggles do nothing and that the WTF is brillant. Please, tell us something we don't know. Those posts are about as stupid as the 'fist' posts.

wintermyute:

Waiting for someone to say that the Real WTF is that the system was written in Perl...

I was wondering what that was.  What the hell is My?  Local variable declaration?

wintermyute:

Awesome.  I like that the guy didn't actually solve the underlying
problem, just kind of swept it a little further under the rug.



I hope he bragged later about fixing the whole app with "1 keystroke!".



Waiting for someone to say that the Real WTF is that the system was written in Perl...

IMHO, as an emergency, fix it in the middle of the night so stuff runs again solution, it's not so bad. Now, if it wasn't brought up with someone and stuck in a "We need to fix this ASAP" list as soon as he got into work the next morning, then its definitely a WTF.

Why on earth would this cause the database AND web servers to freeze? Shouldn't it just log an error everytime it tried to add a new transaction? Surely the web servers should still be able to serve pages even though they can't start a new transaction. . .

Have a field somewhere that is a long value.  Select from this field and use that number.  Update the field by adding 1.  Put everything in a transaction and use the correct locking for your database to keep everything thread safe.

Omnifarious:

Anonymous:

I'm beginning to
think all registered users need an auto-reply to all post feature that
reposts the same thing over and over on every thread.

I have noticed a similarly distressing lack of originality in the
replies. Yes, we all know that some of you think others should be
barred from programming. Yes, we all know that the goggles do nothing
and that the WTF is brillant. Please, tell us something we don't know.
Those posts are about as stupid as the 'fist' posts.

So here's the plan... someone create a bot which monitors the RSS feed
for new WTFs, and as soon as it's there post something like:



fist my useless goggles, this is brillant but I don't see the brillant wtf... etc



Or better, an 'auto troll' to block any post containing 'brillant' and other old jokes!

Anonymous:

Have a field somewhere that is a long value.  Select from this field and use that number.  Update the field by adding 1.  Put everything in a transaction and use the correct locking for your database to keep everything thread safe.

Opps.. meant to quote tthis guy:

Anonymous:

Ok, I have an honest question.

I use a method like this because I need to know the ID number before
I write something to the database (like, to create a link to the new
object in several tables).  So I generate a random ID, check to make
sure it isn't already in use, and return it.

I know MSSQL has an auto-increment option, but how would I implement a non-WTF solution that returns the ID so I can use it?

Anonymous:

I know MSSQL has an auto-increment option, but how would I implement a non-WTF solution that returns the ID so I can use it?

If:

a) the auto-increment MUST be an identity, and

b) you MUST know the new value before actually inserting,

then:

1) Restart reading from the beginning of the specs. You have already read past the WTF, you just didn't realise yet.

2) If you still want this, use IDENT_CURRENT('tablename') and add 1. Make sure to use a transaction and force a table lock before calling the function. Don't forget to send your code to Alex when you're done, then we can all have a laugh at it.

Best, Hugo

Then it's God's fault, is it not?

Omnifarious:

wintermyute:

Awesome.  I like that the guy didn't actually solve the underlying
problem, just kind of swept it a little further under the rug.



I hope he bragged later about fixing the whole app with "1 keystroke!".



Waiting for someone to say that the Real WTF is that the system was written in Perl...

IMHO, as an emergency, fix it in the middle of the night so stuff runs again solution, it's not so bad. Now, if it wasn't brought up with someone and stuck in a "We need to fix this ASAP" list as soon as he got into work the next morning, then its definitely a WTF.

See, all you think that it would be easy for the guy to just put in a fix that uses autoincrement/sequences/etc, but guess what...  What will you do about all the keys in the database already, randomly distributed over the number space, and one can only guess how many other tables and rows are joined using those keys!  It's kinda hard to start assigning them sequentially once there are thousands of randomly generated keys already there.

The solution that he used was the only way to fix it quickly, and perhaps even the only fix even given a moderate amount of time.  A real long term fix would require not only rewriting the id generator, but rekeying the whole database.

wintermyute:

Awesome.  I like that the guy didn't actually solve the underlying problem, just kind of swept it a little further under the rug.

I hope he bragged later about fixing the whole app with "1 keystroke!".

Waiting for someone to say that the Real WTF is that the system was written in Perl...

No comment on Perl, as we all know, you can create a wtf with any language.  What I contest is that he didn't solve the underlying problem.  The website app was freezing up, that was the problem and he solved that. 

Anonymous:

Omnifarious:

wintermyute:

Awesome.  I like that the guy didn't actually solve the underlying
problem, just kind of swept it a little further under the rug.



I hope he bragged later about fixing the whole app with "1 keystroke!".



Waiting for someone to say that the Real WTF is that the system was written in Perl...

IMHO, as an emergency, fix it in the middle of the night so stuff runs again solution, it's not so bad. Now, if it wasn't brought up with someone and stuck in a "We need to fix this ASAP" list as soon as he got into work the next morning, then its definitely a WTF.

See, all you think that it would be easy for the guy to just put in a fix that uses autoincrement/sequences/etc, but guess what...  What will you do about all the keys in the database already, randomly distributed over the number space, and one can only guess how many other tables and rows are joined using those keys!  It's kinda hard to start assigning them sequentially once there are thousands of randomly generated keys already there.

The solution that he used was the only way to fix it quickly, and perhaps even the only fix even given a moderate amount of time.  A real long term fix would require not only rewriting the id generator, but rekeying the whole database.

Since the original value had a length of 6, just start your new sequence id at 1000000.........bingo.

He could convert to an identity by changing the identity seed to something larger than anything in the database.

Rekeying the db isn't as hard as you make it sound.

id = 0
for each borked row
    update row set table.id = ++id where table.id = row.id

of course, updating the FKs is a PITA, but the same logic can be applied. 30min - 1hr job.

Anonymous:

Omnifarious:

wintermyute:

Awesome.  I like that the guy didn't actually solve the underlying
problem, just kind of swept it a little further under the rug.



I hope he bragged later about fixing the whole app with "1 keystroke!".



Waiting for someone to say that the Real WTF is that the system was written in Perl...

IMHO, as an emergency, fix it in the middle of the night so stuff runs again solution, it's not so bad. Now, if it wasn't brought up with someone and stuck in a "We need to fix this ASAP" list as soon as he got into work the next morning, then its definitely a WTF.

See, all you think that it would be easy for the guy to just put in a fix that uses autoincrement/sequences/etc, but guess what...  What will you do about all the keys in the database already, randomly distributed over the number space, and one can only guess how many other tables and rows are joined using those keys!  It's kinda hard to start assigning them sequentially once there are thousands of randomly generated keys already there.

The solution that he used was the only way to fix it quickly, and perhaps even the only fix even given a moderate amount of time.  A real long term fix would require not only rewriting the id generator, but rekeying the whole database.

Meant to quote that.

Anonymous:

REMEMBER FOLKS:

Every time you program like that God kills a kitten.

Are you implying that writing crappy code is akin to self-pleasuring ? Are you a closet WTFer or what ?

Anonymous:

Omnifarious:

wintermyute:

Awesome.  I like that the guy didn't actually
solve the underlying
problem, just kind of swept it a little further under the rug.



I hope he bragged later about fixing the whole app with "1 keystroke!".



Waiting for someone to say that the Real WTF is that the system was written in Perl...

IMHO, as an emergency, fix it in the middle of the night so stuff
runs again solution, it's not so bad. Now, if it wasn't brought up with
someone and stuck in a "We need to fix this ASAP" list as soon as he
got into work the next morning, then its definitely a WTF.

See,
all you think that it would be easy for the guy to just put in a fix
that uses autoincrement/sequences/etc, but guess what...  What
will you do about all the keys in the database already, randomly
distributed over the number space, and one can only guess how many
other tables and rows are joined using those keys!  It's kinda
hard to start assigning them sequentially once there are thousands of
randomly generated keys already there.

The solution that he used
was the only way to fix it quickly, and perhaps even the only fix even
given a moderate amount of time.  A real long term fix would
require not only rewriting the id generator, but rekeying the whole
database.

He could start using an autoincrement but add 1000000 (Or set it to
start at 1000000 if that was possible with his db).  This gets
past all the possible keys that have already been used.

Anonymous:

A real long term fix would require not only rewriting the id generator, but rekeying the whole database.

Re-keying the whole database would be a snap if they'd used the ultimate address book...

From looking at the original code, it does not seem that there were any duplicate keys, but that the key size had exceeded the anticipated length, and that was throwing the system into an infinate loop. I think it would take more than half an hour to fully explore what ramifications changing a primary key would have on a system.

No, I just argued with people on slashdot for a few hours, occasionally
letting out a sigh of frustration to make it sound like I was working
hard on the problem.