Nobody likes to be called a dummy by a dummy.

Won't have time to work on the forum code tonight

I haven't tried to get back into SVN yet but I'm sure it will work from home.

Maybe in the morning I can take a look and add moderation but it won't be this evening, sorry.

If anybody else can get to it before morning EST, have at it.  :)
Permalink Send private email muppet 
January 27th, 2006 4:51pm
actually come to think of it, I may be able to crack it open in about 3 hours or so.

I'll take a look.

I know you're all waiting with bated breath for my updates.
Permalink Send private email muppet 
January 27th, 2006 4:54pm
I'll be gone all weekend (with some limited access via cellphone) so code all weekend and I'll take a look at it on Sunday night or Monday.  ;)
Permalink Send private email Almost H. Anonymous 
January 27th, 2006 4:56pm
If you gave me FTP access to the site, I could upload my own brilliant changes.

;-)
Permalink Send private email muppet 
January 27th, 2006 4:57pm
I'm leaving for VSLive! in San Fran this weekend and not coming back till Wed night. I'll still pop in on the boards, but I won't be making any changes...
Permalink Send private email BigJigger 
January 27th, 2006 4:58pm
Given the progress on your own forums Muppet, I cant wait to see what you can achieve here in, say, 3 hours.
Permalink Say it like it is 
January 27th, 2006 5:01pm
How about having a discussion here to define, specify and prioritise some proposed changes before everyone dives in and starts modifying the code?

We are supposed to be professional software developers, after all...
Permalink Send private email Ian Boys 
January 27th, 2006 5:05pm
I have lots of plates spinning, that's for sure.

AA -

I already hate your framework.  Just wanted to mention...

;-)
Permalink Send private email muppet 
January 27th, 2006 5:05pm
If I mock up some changes what harm will it do?  AA can reject the modifications and revert the code in SVN, no?
Permalink Send private email muppet 
January 27th, 2006 5:06pm
Arg AA why do you make querying so complicated?

I like a good framework with nice cozy abstractions, but damn man, you have to make 8 function calls to do a complex SQL query. 

I need to dig and see if you have a 'cheat' method in here somewhere to just send a raw freaking query.

What's the benefit of the way you're doing it?

PS -

I'm not picking on your code.  It's very organized and I think this place looks GREAT.  I'm just curious why it's done the way it's done.  My database objects are generally very simple, with maybe 5 or 6 methods.
Permalink Send private email muppet 
January 27th, 2006 5:10pm
I put some suggestions in...  otherwise, I'm comfortable with a free-for-all for now.  There are a few key areas that need to be worked on: archives, moderation, search.

"I already hate your framework."

*sniff* that hurts my feelings.  What's to hate about it!  It rocks...  well...  except for the "total hack" parts.
Permalink Send private email Almost H. Anonymous 
January 27th, 2006 5:12pm
Mostly I'm talking about your database includes.  Holy hot damn, man, talk about a lot of time spent on something that PHP already makes very comfortable.  :-)
Permalink Send private email muppet 
January 27th, 2006 5:14pm
"Arg AA why do you make querying so complicated?"

You mean more complicated than a bunch of raw string concatination?

It's very simple once you get the hang of it. 

"What's the benefit of the way you're doing it?"

A couple of things:

* You can SQL-injection safety for free.
* You pass the query object to functions which can add where clauses or other filters to the query.
* It abstracts the SQL so it's easy to change database engines.  (Admittedly, not an issue here).

Other than that, I just don't like big multiline SQL strings in my source code.  ;)

To send a raw query, just methods on Database_Connection object directly.  That's stored in $GLOBALS[CONNECTION].  It has all the same methods as the select.
Permalink Send private email Almost H. Anonymous 
January 27th, 2006 5:18pm
So if I just throw a bunch of raw queries in the code, you can fix 'em later and not bitch at me about it, right?

...right?

:-)
Permalink Send private email muppet 
January 27th, 2006 5:24pm
Sure.  Why not.
Permalink Send private email Almost H. Anonymous 
January 27th, 2006 5:27pm
Any chance you can figure out why blank people show up as zero.  It seems to me there's some kind of weird number conversion going on in places.  FNR said is post containing just "19." turned into "19.00".

I haven't had time to track that one down.  It's just weird.
Permalink Send private email Almost H. Anonymous 
January 27th, 2006 6:02pm
I'll look for that tonight since I doubt I'll make changes until I figure out the DB objects.  :)
Permalink Send private email muppet 
January 27th, 2006 6:18pm
19.00
Permalink Send private email Mat Hall 
January 27th, 2006 7:13pm
My guess (although it's based on not having looked at the code) is that it's just a side-effect of PHP's almost pathological lack of types, so shouldn't be too hard to fix; I'm guessing that the closing </div> after the post body is written out independently of the post itself, but by combining them first (concatenate the '<div class="discussBody">', the body of the post, then the '</div>' and write THAT out, it should avoid any typing issues?

(On the other hand I could be talking arse.)
Permalink Send private email Mat Hall 
January 27th, 2006 7:17pm
Oh shit.  I think I just figured it out.  I think has something to do with the PHP -> MySQL interaction.  It's probably MySQL that is adding the decimal points.  I'm not sure it explains the 0 on empty names though.
Permalink Send private email Almost H. Anonymous 
January 27th, 2006 7:22pm
Why would MySQL add decimal points in a TEXT typed field?

You mean it has something to do with your lame assed DB objects?  ;-)
Permalink Send private email muppet 
January 27th, 2006 7:28pm
I can't think of a single reason wy MySQL would be adding decimal points.  PHP, on the other hand, may be being "helpful".  (Why not take a peek in the raw table, and see what's in there?)
Permalink Send private email Mat Hall 
January 27th, 2006 7:33pm
Shuttup!  It's an easy fix.  Do you want me to point it out to you?
Permalink Send private email Almost H. Anonymous 
January 27th, 2006 7:38pm
Since I'm busy playing Eve Online and not looking at your code I guess you'd better.

;-)
Permalink Send private email muppet 
January 27th, 2006 7:40pm
Matt,

INSERT INTO table (sometextField) values (19.)

In this case, it looks like MySQL pads it out to 19.00 before assigning it to the text field.  Which is perfectly logical.

The code is being helpful and passing the number as a number as opposed to passing it as a quoted string. 

INSERT INTO table (sometextField) values ('19.')
Permalink Send private email Almost H. Anonymous 
January 27th, 2006 7:41pm
God aren't you terminally bored with that yet.

I lasted 3 days, no whole days, though it felt like it.

Once the computer with the nice voice went away it just got old quickly.
Permalink Send private email Simon Lucy 
January 27th, 2006 7:42pm
Oops too late, gotta go.  Good luck!
Permalink Send private email Almost H. Anonymous 
January 27th, 2006 7:42pm
Ok, it's MySQL doing the padding, but I still maintain it's a PHP weakness.  I'm guessing the code is something like

INSERT INTO table (sometextField) values ($postBody);

Because PHP isn't strongly typed it's telling MySQL that it's a numerical value of 19 and not a string containing 19, so you have to manually 'cast' it.  Weakly typed languages are a pain in the ass -- if this were an ASP app then bodyPost would have been defined as a string and the problem would never have arisen.  So, I still maintain it's PHP's fault, not MySQL. :)
Permalink Send private email Mat Hall 
January 27th, 2006 7:50pm
Even given the explanation, I think it's PHP.
Permalink Send private email muppet 
January 27th, 2006 7:51pm
"I still maintain it's a PHP weakness."

It's not PHP weakness, it's a bug in the code for this site.  Using the is_numeric() function, the code determines that it's a string containing a number and passes it along to MySQL as a number.  This is by design.  Now normally I'm not writing a forum so this is correct behavour; when someone types a number they usually want a number.

The fix is pretty simple: replace is_numeric() -- which is designed to operate on strings -- with (is_int($value) || is_float($value)) so that only actual numbers (not numbers in strings) are passed to MySQL as numbers.

I never claimed that it was the fault of MySQL..  only that MySQL was doing the conversion.  That was the realization I needed to find the bug.
Permalink Send private email Almost H. Anonymous 
January 27th, 2006 8:05pm
"It's not PHP weakness"

Having to explicitly cast variables all the time to avoid unexpected behaviour, rather than being able to say "whatever happens, this is a string", is a weakness... :)
Permalink Send private email Mat Hall 
January 28th, 2006 4:47am
Matt,

I think you're missing the point.  This is about generating a SQL string -- that operation wouldn't be any different in any other language.  You have to explicitly quote or not quote the values.  The bug would be just as easy to produce in say Java or C++.
Permalink Send private email Almost H. Anonymous (mobile) 
January 28th, 2006 2:32pm
I'm sure that in every other language I've passed values to a database from if the thing I'm passing has been explicitly declared as a particular datatype it's gone in as that datatype and if I pass the "wrong" type it throws up.  PHP suffers from essentially only having a variant datatype, so while it may be MySQL that's actually doing the implicit casting it's only because PHP isn't saying "I'm passing you the string '19.'" it's just saying "I'm passing you '19'" and MySQL has to make an assumption; it makes the "wrong" one, sure, but that's not it's fault, it's just because PHP doesn't make it clear what it's doing.

(I've always made the habit of explicitly casting EVERYTHING in PHP to avoid precisely this kind of nonsense -- because you'll get no errors putting, say, a string into something that should only have a date in it, unless you check everything first you're opening yourself to a world of hurt; it could be as minor as the "passing a float to a string function and getting something odd" to "passing an unchecked string to a date field, and due to your assumption it *is* a date and not checking, trying to stick "'); drop database FruitShow;" into a field and wondering where your database went.)

Weak typing is handy sometimes, but (as any VB6 developer will tell you) it's more often than not the source of really irritating bugs...
Permalink Send private email Mat Hall 
January 28th, 2006 7:18pm
(Disclaimer -- I'm drunk. :)
Permalink Send private email Mat Hall 
January 28th, 2006 7:23pm
Matt, you're so full of shit that I don't know where to begin.  I'm way too drunk to reply.
Permalink Send private email Almost H. Anonymous (mobile) 
January 28th, 2006 11:16pm
Having re-read that in the cold light of day it was somewhat rubbish -- beer is the enemy!  However, as a matter of course you ought to be doing something like this with EVERY string you pass to the database, regardless of where it comes from:

function quoteString($str)
{
  return("'".str_replace('\\"','"',addslashes($str))."'" );
}

(Apologies if you're already doing similar, but I don't have much time to look at the code now so I've not bothered. :)
Permalink Send private email Mat Hall 
January 29th, 2006 6:24am

This topic is archived. No further replies will be accepted.

Other topics: January, 2006 Other topics: January, 2006 Recent topics Recent topics