RE: [CFCDev] Ad-hoc queries using Data Gateway objects

[RADEMAKERS Tanguy]

Title: Spam:RE: [CFCDev] Ad-hoc queries using Data Gateway objects

Hello,   I've got a question about using these filter/criteria objects.   Say i have three basic attributes to filter on: - color - size - shape   How would i use a filter/criteria object to indicate that i want a record set of all widgets "...where color=blue or (size=large and shape=triangular)"?   I can see how to make all criteria AND or OR together, but how would i mix and match?   Regs, /t From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Duba, Phillip Sent: Wednesday, January 11, 2006 3:02 PM To: CFCDev@cfczone.org Subject: RE: [CFCDev] Ad-hoc queries using Data Gateway objects Ok, that makes sense since I thought the getById() method took a single id value not a list of them. My DAOs have something similar to your read() method and they always return a singular object whether it’s read or saving data. As for the filter method, wouldn’t this be a good place to pass in a structure and loop through that structure to create the dynamic where clause? I figure whatever you may be using as a controller can construct the structure and pass it into the method this way you don’t have to worry about StructKeyExists() or IsDefined() or default checking. That’s the tact I would probably take. The difficulty would be in synching the structure items with the fields in the database. Thanks,   Phil   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Seth Johnson (KW) Sent: Tuesday, January 10, 2006 10:28 PM To: CFCDev@cfczone.org Subject: RE: [CFCDev] Ad-hoc queries using Data Gateway objects   Phillip:  my getById() method accepts a LIST of data, not a single value, and therefore can return a multi-row query.  For this reason (and the fact that the resulting data is a query, not an object) I put it in the Gateway object.  My DAO already has a read() method that accepts a single value and returns a fully constructed object.   Jason:  I like the idea of naming the filter object Filter, not Criteria.  I'm kinda embarrased to admit I thought long and hard for a good name for that object and "filter" never occured to me :)   Nando:  I use the same distinctions you do: DAOs synch up the database and singular objects, while Gateways return queries.  My main question was:  in my ad-hoc query method, is it better to have an argument for EACH field that can be searched, or is it better to construct the filter as a separate object and then pass a SINGLE argument (that filter) into the Gateway's ad-hoc query method?   Basically, if I have a table with 20 searchable fields I don't want to have to deal with 20 method parameters.  I'd rather construct the entire filter as an external object and then pass it into the search method, but I wasn't sure if anyone else was using the same approach (or had something better to suggest).   Thanks everyone for your comments!   Seth ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org