You mention that you have a 'hash of hashes' but then go on to say '3 or 4 levels down'?

The major benefit of using a hash is that it avoids the need to search.

A second benefit of a hash is that as the elements are named, it allows the addition of new elements without requiring code that references existing elements to be changed.

If you know the 'path' to your elements, use it. Otherwise what is the point of building the hash in the first place?

I fail completely to see why you think using the structure in the way it is designed to be used is in any way a 'cop out'.

• After reading this post, the first thing pop up in my mind is that, we are simply not ready to talk about the search algorithm yet. Although searching algorithm is important, don't forget, an efficient searching algorithm always requires a specific and efficient way of organizing your data.
  
  If your data is poorly organized, no searching algorithm will be able to fully demo its power.
  
  There are lots of choices over there, from a simple queue to a balanced binary tree, ... If I am doing this, I would refer back to those books I read during the good university time, those helps in this situation.
  
  
• After you picked your data structure, the way your data is going to be organized. The next thing is to find and define a way to represent your data structure in Perl.
  
  As we don't really know what the nature of your data is, it is hard for us to give any detailed suggestion on data struecture, not to say the Perl representation, but I DO seriously suggest you to look into the available data structures that fit your purposes and your data's charactristics.
  
  
• Finally, it comes the time for you to determine your searching algorithm.
  
  

Why not have a master index hash, which would link strings to their entries in the HoH?

Can a string occur more than once? In that case, you probably want a master HoA, with each entry in the A being a pair of "key list -> reference".
--
Mike

1. The point of using a binary search is specifically to avoid doing an end-to-end search of the entire tree. However, it's only of value if the data in the subordinate hashes are collectively in sorted order. I'm betting they're not.
2. Off the top of my head, I can't think of a way to shorten the search if those sub-hashes aren't in sorted order. I think you're in for a hash-tree variant of an old-fashioned sequential search.

Which, unfortunately, has you back where you started.

- Steve

Uhm...how do I delete my own response?

You could consider reading the structure into an XML DOM object, that way you can use XPath expressions to query the data.

Hope this helps, -gjb-

One thing to say is that if this is any sane kind of config file, i.e. way smaller than Sendmail's, then who really cares about efficiency.

Next, if you mean the config data is something like a hash of hashes, of hashes, of hashes then obviously you can find your data like $val = $cfg{section}{subsection}{param}{option} and that should be very efficient.

Now if you are wanting to search the entire HoHoHoH for certain values, the most efficient way is probably going to be to make an inverted index. For example you could make a hash that looks like $inv{"$val_$instance"}="$section_$subsection_$param_$option" where $instance is just a counter which lets you maintain records for multiple occurrences of the same string in different parts of the config file without overwriting old hash entries.

The point of the inverted index is that you trade a little time at the beginning for the ease of being able to just read off the value at the end. Probably you can even use grep with a regular expression on the keys of the inverted index. Come to think of it, you could just run a pattern match on the config file itself and the heck with all this hash stuff no? Hard to see your exact requirement.

About implementing a real search algorithm, it would probably make more sense if you are talking about a lot of data and you also know a lot about the kind of data you have and where it will be in the structure.

Some other neat links I was finding in CPAN.. Search-InvertedIndex, Tie::Hash::Regex (mentions PM!), Data::Hash::Flatten (also mentions PM, and your problem!). And last but not least, Data-DRef (thanks to princepawn's post in the Flatten thread) which looks useful in the "matching_keys" and "get_value_for_key" methods (caveat emptor, haven't used it myself). Dref stuff looks neat and flattens it all for you.

Hope this helps!

I love this site!

it appears that everyone has contributed in some way to that question I posted. The configuration file that I'm trying to parse is a proprietary log filter configuration file created by CheckPoint. I'vei searched for various perl modules or what not that can parse the data, and get it into perl so I can parse various log files automagically without having to load up the client/server application that normally does the parsing.

I can possibly dummy down the configuration file i['m dealing with, but I dont necessarily want to post it in a public area. If anyone is interested, please feel free to Private Message me and i'll see what I can cook up.

There's a real perl guru here where I work, unfortunatly I dont really want to bother him too much. He's gotten me to the point of getting the data into perl via the Parse::RecDecent module. Now I just need to figure out how to access the data I need out of that complex data structure.

Really, the information I need is only three things from each selection rule, the "type", "val" and "is". Type always returns a scalar value. val can either return a scalar, or list, and "is" is boolean (either data is included from this selection rule, or excluded from the output).

I realise trying to answer a question when posted in a vague way is difficult, and I appologize. After having this issue rack in my brain all weekend long, I've realized how compledx a question I've posed, and that it's d*mn near impossible to solve without an example of the data source, or datastructure returned by data::dumper.

Let m e see what I can cook up with a dummied down version of the configuration hash, and I'll send it to whomever is interested.

Regards,

-=-GardRail-=-

s/[a-zA-Z1-9]/x/g ?

Update: thanks whoever gave a minus minus.

I mean he can share a few lines of the config file by replacing all the alphanumerics with x's, so we can like, you know, help. At least when I tried it on the command line this regex worked fine for me.. yeesh.