in reply to Re: Newest node page - order of nodes
in thread Newest node page - order of nodes

I recently discussed this with Chmrr. My idea was to have an update system for root nodes. It would require two new fields for root nodes (Last Modified, Note ID) and an additional table. One would be presented with a textarea to make an ammendment to the node, this entry would be timestamped and stored in the Note ID table. Last Modified and Note ID in the root node table would be updated. Subquent updates would be prepended to the existing note. When the root node is displayed the note would be prepended to the node body when displayed. Finally, Newest Nodes could pick up on touched Last Modified fields.

--
I'm not belgian but I play one on TV.

  • Comment on Re**2: Newest node page - order of nodes

Replies are listed 'Best First'.
Re: Re**2: Newest node page - order of nodes
by PodMaster (Abbot) on Feb 10, 2003 at 02:14 UTC
    Why?

    A node already has a "createtime" and "lastupdate" and even a "lastedit" field. I cannot see what adding yet another field and creating an additional table would do.

    You know how we have messageonreply, what no a messageonupdate? Everytime a node is updated, it would send a message to a special group, something like SystemNodeUpdated and then people could go to the messageinbox, with 'recipient' being that of SystemNodeUpdated, and view the messages, which would look something like:
    <SystemNodeUpdated> says "PodMaster updated Re: Re**2: Newest node page - order of nodes on Mon Feb 10 02:22:22 2003 GMT"

    update: I guess adding a table to keep track of this could potentially lead to some kind of database indexing optimization ... i'm not convinced we need it.


    MJD says you can't just make shit up and expect the computer to know what you mean, retardo!
    ** The Third rule of perl club is a statement of fact: pod is sexy.

      Well, we have lastupdated then that takes the place of Last Modified. And while a seperate table for notes is not required (could be a column in the root node table), I suspect most root nodes will go un-updated. The purpose is two fold.
      1. To allow updates to be seen by the most people in the manner which they are accustomed (Newest Nodes).
      2. Thereby removing any excuse for posting a new root node as an update.

      --
      I'm not belgian but I play one on TV.