> 1. Query a verity collection, return the results as "key, > title, body" (also get back a score) > 2. Query a 2nd verity collection, return the results as "key, > title, body" (also get back a score) > 3. Create a structure to hold the results. > 4. Create an Array to hold the structure. > 5. Loop over the first set of results, storing everything AND > the score in the struct, then storing that as an entry in the > array > 6. Loop over the second set of results storing everything AND > the score in the struct, then storing that as an entry in the > *SAME* array. > 7. Now I should have an array that has a structure containing > a key, a title, a score and a body for each result (it's not > a lot of information, just a string). > 8. Sort the array by the score, combining the results of both > collections and outputting them with the high scores at the > top (naturally). > > Is that so hard to do? Am I thinking of it wrong? Is my > approach somehow wrong?
It seems to be much more complicated than it needs to be. > Each collection (and once I figure it out for two collections, > there will be MANY collections eventually added) contains a > small amount of data that will need to be displayed differently, > depending on which collection it came from. I want to *present* > the results, sorted by score as "one" result, but each link will > be passing a variable that will determine how it's displayed > on the following linked page. > > Make sense? That's why I can't just search a bunch of collections, > because *which* collection the result came from will determine > how it's going to be displayed. You can probably do this all with one single collection, if you like. You can probably also do it with multiple collections, but with a single search. All you have to do is store some differentiating factor in Verity, then use it to determine how you'll display things. If you're storing indexed database queries, you can easily do this when constructing your key. For example, let's say you have two tables, and you want to index both into a single collection. You could differentiate them by including the table name within the key that you give to Verity: <cfquery name="qPerson" ...> SELECT mykey = "person:" + CONVERT(varchar, PersonID), ... FROM person </cfquery> Then, within your display code, you could parse the key - in the above case, using the colon as a separator - to find both the table and the primary key within the table. Alternatively, you could store information in the CUSTOM1 and CUSTOM2 fields - that might be a little easier, but wouldn't allow you to index more than one table within the same collection if you're using surrogate keys generated by identity columns or the like. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/lists.cfm?link=t:4 Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm
