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 :$

Well it's not pure SQL at that point, it's getting into database-specific programming languages.

And I guess, especially compared to more general programming languages, they're a bit crappy - they're static typing, still needs some form of front-end to be useful, and stuff.

I don't think it's going to be quick, so I'll wait to post it.

OK I've attached a screen shot of the current report and my code. Here is what I need to do, and fucked if I know if I can do it.

 

In the screen shot you can see that everything in the description field is Red Oak except one (which is White Oak). This can change to anything.

 

For example we could have a batch of Cherry and then one Hard Maple in the batch.

 

So what I need to somehow do is get a majority of the type of wood it is and ignore the minority. Pretty complicated....

I'm still busy, but want a quick break, so anyway...

<!---
	Count how many of each wood type is used...
--->
<cfset WoodTypes = [] />
<cfloop query="batch_report3">
	<cfset WoodName = extractWoodName(Description) />
 
	<cfif StructKeyExists(WoodTypes,WoodName)>
		<cfset WoodTypes[WoodName]++ />
	<cfelse>
		<cfset WoodTypes[WoodName] = 0 />
	</cfif>
</cfloop>
 
<!---
	Work out what the most common wood type is...
--->
<cfset MaxCount = 0 />
<cfset MaxType = "" />
<cfloop item="CurType" collection=#WoodTypes#>
	<cfif WoodTypes[CurType] GT MaxCount >
		<cfset MaxCount = WoodTypes[CurType] />
		<cfset MaxType = CurType />
	</cfif>
</cfloop>
 
<cfoutput>
	<p>Most common wood type is "<b>#MaxType#</b>".</p>
</cfoutput>
 
 
<!---
	Extract the name from the description.
	(May need changing/expanding depending on other description formats.)
--->
<cffunction name="extractWoodName" returntype="string" output="false" >
	<cfargument name="Text" type="string" required />
 
	<cfset var Name = rereplace(Arguments.Text,'^\d/\d x RW','') />
 
	<cfset Name = rereplace(Arguments.Text,'(?:prime|\da?)? (?:common|boards|unselected|blocking) green') />
 
	<cfreturn Trim(Name) />
</cffunction>

If one of the many crazy columns has just the wood name on its own, you don't need the extractWoodName bit.

I didn't test that, so there might be bugs in it, but hopefully not.


Oh, and that only returns one maximum, so if there's like 5 Cherry, 5 Hard Maple, 2 White Oak, it'll say "cherry" OR "hard maple", but not both.
Don't know if that's good enough, or if you do need to cater for that?



If I wasn't busy, I'd suggest a billion ways to make your code look nicer, but I will say just two things:

TABS ARE YOUR FRIEND!
Identing blocks makes things MUCH easier to read.
(Although using eight space for it, like Firefox is doing above, is a tad annoying.)

Also, you don't need lots of those #s - they basically only need to be used when outputting HTML/etc (i.e. inside cfoutput), or when using a variable in a string (i.e. inside "quotes"), but generally not in cfset tags.