I'm not understanding something because that looks like you're creating a table for each node type and the rows of said tables are the edges.

You've got it. The only part you're missing is that isn't "just" a graph system. It's Krang, the purpose of which is not to be a general graph implementation but rather to publish webpages. The fact that dumping and loading data is essentially a cyclic-graph-loading problem is more a side-effect than a design goal.

In this case each node type is a completely different kind of data - stories, templates, media, categories, users, etc. The links are forgeign keys in the tables, category_id in the media table for example.

Does that make sense?

-sam

So, the links are literally that - actual weblinks. *ponders*

Either way, it doesn't matter. Create a links table and load that after loading all the nodes in their various types. That's the cleanest solution. Loading the links at the same time as the nodes is going to run into problems with cycles. But, you already knew that.

An alternate solution is what Data::Dumper does and that's to keep track of what nodes have been seen before and stop following the tree when you find somewhere you've been. I don't know if that will work, given the code you've already written.

---

• In general, if you think something isn't in Perl, try it out, because it usually is. :-)
• "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"

So, the links are literally that - actual weblinks.

Sometimes. Story to story links are usually real links. Story to user links, for example, aren't. They link a story to the user that created the story. There are more non-weblinks in the system than weblinks.

Both your solutions are reasonable. In fact, what I'm doing now is sort of like both. Neither is what I'm after here, but maybe what I'm after doesn't exist.

-sam