Re^2: 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. Read more... (2 kB) TIMTOWTDI! 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	[reply] [d/l] [select]
Re^4: Pivoting parts of a database table into an HTML table by Anonymous Monk on Oct 23, 2012 at 07:20 UTC
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.	[reply]
Re^5: Pivoting parts of a database table into an HTML table by jandrew (Chaplain) on Oct 24, 2012 at 17:37 UTC
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.	[reply]