Any idea how their software does the above SELECT Statement and it's what I captured on the SQL Server but when I try to execute it outside of their software it tells me these aren't defined?

=ISNULL(p2.prdUsrAttribID,'') AND ISNULL(p1.prdUsrAttribID2,'')=ISNULL(p2.prdUsrAttribID2,'') AND ISNULL(p1.prdUsrAttribID3,'')=ISNULL(p2.prdUsrAttribID3,'')  
AND ISNULL(p1.prdUsrAttribID4,'')=ISNULL(p2.prdUsrAttribID4,'') AND ISNULL(p1.prdUsrAttribID5,'')=ISNULL(p2.prdUsrAttribID5,'')  AND ISNULL(p1.prdUsrAttribID6,'')=ISNULL(p2.prdUsrAttribID6,'') 
AND ISNULL(p1.prdUsrAttribID7,'')=ISNULL(p2.prdUsrAttribID7,'')  AND ISNULL(p1.prdUsrAttribID8,'')=ISNULL(p2.prdUsrAttribID8,'') AND ISNULL(p1.prdUsrAttribID9,'')=ISNULL(p2.prdUsrAttribID9,'')

Disregard, I have that mother fucker working!

This is why I like ORMs.

What's ORMs?

http://en.wikipedia.org/wiki/Object-relational_mapping

I don't think I'm smart enough for that. OO confuses the hell out of me. That's why I stick with a BASIC like language that flows from top to bottom!

ORM is a way for people doing things wrong to make it easier to keep doing things wrongly. :P

It does make things a lot easier, as you don't have to use SQL - you interact with the database in terms of the language you're using to write the applications. For example, Rails lets you do stuff like:

Post.destroy_all :user => User.find_by_email("andy@caerphoto.com")

When you strip away all the crap, OO itself isn't that bad. (Though it's also not the One True Path.)

It's all the unnecessary over-complicated crap, like ORM and silly design patterns and so on, that makes it seem scary.

That looks even more complicated :$

If you don't want to use SQL, don't use a database that runs on SQL! ( :O )

Than what? I'm not sure what the corresponding SQL would look like but I'm pretty sure it'd be more complicated than that.

I'm not...

DELETE Post WHERE Creator = findUserByEmail('andy@caerphoto.com')

Will that also trigger any callbacks set up in the Post model, for example if it's the last Post being deleted, also delete the associated Thread?

And what is this 'findUserByEmail' function?

Pete are you up for a complicated question?

Yes, of course, (because that's how my imaginary SQL database has been configured to react).

(It's been possible to do triggers with databases for years, long before Rails came along. Probably even before Ruby too.)


It's a function (stored procedure), just like your User.findByEmail one. It's automatically generated by another one of those triggers - every time a table is created or altered - so it's faster than doing dynamic lookups with Method Missing.

If it's a quick complicated one... I'm supposed to be finishing something off at the moment, but keep getting distracted by that dastardly Rails fan. :@

Well now, that's interesting.

I'd best not get too involved in this as I really don't know all that much :$

The difference is, nobody has actually created a popular framework for all this stuff (well, not that I'm aware of), but the ability to do it is there.

Very little (if any) of the stuff that Rails (or others) is new - it's all been possible for decades, but either computers were too slow, or it just didn't get used in mainstream until someone actually shouted about it.

Hmm. Why's nobody made a popular framework for it? Is that sort of thing possible in SQL? Man I really don't know much about server things :$