Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses

Re^2: Pivoting parts of a database table into an HTML table

by Anonymous Monk
on Oct 22, 2012 at 15:16 UTC ( #1000363=note: print w/replies, xml ) Need Help??

in reply to Re: Pivoting parts of a database table into an HTML table
in thread Pivoting parts of a database table into an HTML table

Hmm... looks like I forgot to mention that using the iterator would be nice, rather than slurping it all into a hash. The iterator also guarantees the order (dates in order, woody words before tinny), being from a database and all. Which would have much reduced the sorting need I hope.

Anyway, I've yet to study your code properly, but right now I'm thinking of wrapping my iterator into a second iterator that buffers a day's worth of words. (Dominus's book seems to have had an effect on me.) It's not the nicest answer but one of the easier ones I guess.

  • Comment on Re^2: Pivoting parts of a database table into an HTML table

Replies are listed 'Best First'.
Re^3: Pivoting parts of a database table into an HTML table
by jandrew (Chaplain) on Oct 22, 2012 at 17:45 UTC

    Athanasius's solution is the traditional perl solution for the problem you presented. In other words put the data in a hash (to organize the pivot) and then post process the output.

    If you are trying to leverage some of the databases functionality as you indicated in your second post then you may want to consider $hash_ref = $sth->fetchall_hashref(); rather than the database sort.

    If the goal is to use chapter 4 of Dominus's book to minimize memory overhead then you really just have a recursive problem where you need to identify your base state. (a change of date) You might find the following useful in that case. The data must be pre-sorted by date for this to work. Width formatting is not possible in this output since the data will be printed prior to a test of all rows. That shouldn't be a problem for your suggested goal of web output.


    Update1: changed for to while to honor the iterator concept

    Update2: I just noticed I didn't pick up the last line (no base state test when the query ends. (fixed))

    Update3: fetchrow_hashref is a better fit and can be used with sort

      Thank you, that helped a lot. I guess my problem was trying to force two state change points (date and type), which makes quite a bit sense but apparently introduces too much complexity I can't deal with.

        You could use type as a state change point but your column allocation would fail for 03 Oct (Wed) since the first type was not available that day. If you reversed the type sort order then you would fail on 29 Sep (Sat) and 02 Oct (Tue) for the same reason. To allocate the correct content to the correct column then you need to pre-define type names applied to the column and still store both sets of type content until the date changed. Doing that you loose any (minor) memory advantage gained from recursively parsing the type. You would also have problems if three types were defined later and you only wanted to display two.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1000363]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (2)
As of 2018-04-22 12:42 GMT
Find Nodes?
    Voting Booth?