Re: seeking in hash data structure

You want a query language. Two come to mind:

XPATH. It's used on tree structured data, pretty much as you have here. You'll need to wrap your HoHoHoH as an XML doc to use it.
SQL. Used on table data, but that might suit you pretty well, you just need to model your data properly (i.e. define a 'Company' as a something which has a 'name' and possibly many 'Application's, possibly many 'People').
Check out the DBD::RAM module if you don't want to mess about with any persistence issues, DBD::SQLite if you don't mind/actually want simple disk storage or MySQL/Postgres if you're that kind of person.

Either way, you'll be defining your underlying types ('Company', 'Application') a little more, which I suspect is the underlying reason you keep running into this issue.

You're make perhaps too much use of the fact that perl doesn't force types down your throat and are hence thinking of everything as a hash rather than an abstract type.

If so, maybe just defining a few struct-type classes will give you places to put your query methods without the need to go to a generalised query language like the above.

Comment on Re: seeking in hash data structure

Replies are listed 'Best First'.
Re^2: seeking in hash data structure by Corion (Patriarch) on Oct 25, 2006 at 08:58 UTC
There is Class::XPath, which allows you to graft XPath queries onto almost any class structure. Also, there is Data::Diver, which has its own query "language" to access elements without autovivification. Using a database incurs a lot of front-up work which may or may not pay off in the long run, as for every addition to the data format, the SQL schema needs to be modified. LDAP seems more suited for storing unstructured or semistructured hierarchical data.	[reply]
Re^3: seeking in hash data structure by jbert (Priest) on Oct 25, 2006 at 10:05 UTC
Ah, I didn't know about Class::XPath. Looks very nice, and almost exactly what the doctor ordered. As far as I can see, Data::Diver doesn't allow the more general kind of querying which the OP requested. And whilst LDAP has a special place in my heart, as far as I know, it has the same schema issues which SQL does. LDAP object classes need to be defined in terms of mandatory and optional attributes, the attributes need to have an appropriate syntax. Basically LDAP object class == SQL table, LDAP attribute == SQL column. The main differences IMHO are that LDAP gives you a heirarchically-defined name for each entry and SQL gives you a richer query language. I would agree that DBs aren't the answer to everything, but they are an answer to "how do I do fairly arbitrary queries to my structuted data".	[reply]