Tuesday, May 30, 2006, 5:59:09 PM, one spoke: AD> Agreed. I would be very interested in hearing the advantages of AD> converting a query to an array of structs given you can access AD> rows and columns from a query "natively".
Well, if your child tables have child tables, or if there are multiple child tables, it can help a lot to have the actual hierarchy parceled out once. e.g. my never-ending bugbear, the quiz: a quiz is a bit of metadata, with a collection of questions hanging off of it, each question with a collection of answers hanging off of it ... (I won't even get into userresponse and userselection records here :^>). Grabbing the third option to the fifth question is pretty straightforward in a struct of structs; it's a PITA in a recordset. And if I'm in authoring mode, what would I be doing, using QuerySetCell() and QueryAddRow() etc.? If I added three Q/A sets in a session, how would I be able to go back and revise them before I roundtripped to the db to get new primary keys for them? The question (and mine too), is whether those collections are arrays of objects, or structs of objects, or arrays of structs, or structs of structs, when they get populated, how they get populated, where the save() methods go, what object knows the sequence (i.e. what object does the controller talk to when the author decides to move a question from #4 to #8) -- the quiz object has the whole collection but the _seq column's in the question record in the db ...). etc. etc. (Can you tell how many times I've refactored this app in the last three years?) -- Jim Flannery [EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
