in reply to Re^8: Perl Database Entries
in thread Perl Database Entries

What is the difference between  my $unjson=$json->allow_nonref->decode($api_results); and

my @unjson=$json->allow_nonref->decode($api_results);
What happened differently when you replaced the $ with @? what was the contents of @unjson in your version

What is the difference between

for my $row (@unjson) {
and
for my $row (@$unjson) {
What happened differently between the two after the change to @unjson=

What is the difference between

for my $var (qw/.id .slug .name .provider.id .provider.name .../){
and
for my $var (qw/.id, .slug, .name, .provider.id, .provider.name,.../) +{
What happened differently after you made that change

Yes the substr removed the leading dot, but its presence was more to remove a leading blank token after the split. The purpose of the split had less to do with removing the dots but instead broke the value into its subparts that were separated by the periods. $row is a hash reference, we did not transfer any json data in that assignment but instead made a copy of the pointer into a working variable that we could then modify without consequence. The scalar value of an array is the number of members in that array. The loop will only first execute if there was more than one period separated subpart to the name/value and will continue to execute while there are still subparts to deal with. $subpart represents the next value in the chain of array references we want to deal with. $base=$base->{$subpart}; then places into $base the reference to the subarray we named via $subpart. if $var was a.b.c on the first loop of the while $base now points to the hash $row->{a} instead of $row. on the second pass of the while loop $base will become $base->{b} which would be the same as $row->{a}{b}. As pop removed subparts from the array the loop finishes when there are no more subparts left in the array and $base is left as the pointer to the deepest hash we need so that $base->{$terminal} will point to the value of the last name of the original @parts. IF there was only 1 subart in the original @parts $base still points to the original hash of $row. if there were 2 subparts left after terminal was popped off, such as in a.b.c $base now points to $row->{a}{b} and $row->{a}{b}{c} would be placed into @insert. If there was only a terminal in $var (such as d) $row->{d} would be placed into @insert since $base would have never been changed from its original setting of $row.

What was the difference between what you posted as $api_results in Re^4: Perl Database Entries and Re^6: Perl Database Entries. What was still wrong with the supposed json in Re^6: Perl Database Entries, (hint there were two errors that poj fixed for you without mentioning them)

So you skipped explaining what went wrong when you changed what i posted, you still dont understand how not telling us what your data was or why posting incorrect data presented a problem in determining what needed to be done, and you dont understand what happened when you changed the for $var (qw/.../) sequence. Given the explanation above ill let you grade yourself on your understanding of what the perl simulation of jg did

.

Replies are listed 'Best First'.
Re^10: Perl Database Entries
by huck (Prior) on Jul 17, 2017 at 02:04 UTC

    Addendum

    And as a seasoned member, you would be more progressive in your didactic efforts if your prose were less drenched with condescension and judgmental overtones.

    In general i am less inclined to be "didactic" and more likely to be "Socratic" instead. What i saw was someone who had done a very strange thing "|\@csv" in their original post, who seemed to have no idea what DBI/DBD was doing for them $api_results->fetchrow_array()) and complained about an error message they did not seem to have researched themselves. Yet thru questioning i was able to drag more information out of you about the actual problem set.

    You then showed us the results of the curl to jg pipe (well with the "funny tee") and i realized i didnt want to walk you thru using a CSV module to parse that and the double quotes would mess up any simple split and proposed a new path. When i use LWP it takes a half a dozen utility statements to set up a ua,request with possible headers, test for a valid response, and selecting the decoded output besides doing the actual request itself. And i prefer to do that so im sure of what i am doing rather than guess on on what something like LWP::SIMPLE is doing in the background. You had a curl request that seemed to work and i would just let you to deal with it failing on a 4/500 error response rather than try to explain what of of that utility was doing. I showed a method that would let you continue to use curl, but "skip jg" and CSV and go directly to JSON. And i thought you did pretty good by finding my cut and paste error.

    But then you come back with more errors, and imply that you hadnt tried to solve the problem yourself. you claimed that $api_result was something it could not have been. If you had run your initial statement it would not have been that because of the strange final pipe ("|$arraysomething>..") or if you had run my change it would have been a json string. Your claim showed that you had not even done a print $api_results; to see what was in it before complaining about an error that not would have happened if you did what i suggested.

    Then you came back and listed something as your $api_results that again could not have been what was in it. It was missing both an initial bracket and a double quote. And mysteriously the error changed without you admitting you had changed something or telling us what you changed. And i saw what you had done with the assignment to an array, and the change to the $row loop, again without mentioning it. It became clear that you dont understand array/hash references and in changing it to an array reference you had no clue as to what you did and how it affected the $row loop. Nor did you understand qw and what the added commas in it affected. After figuring out what was wrong with the json you posted i did realize what those strange names to jg were doing and proposed a rather simple solution to deal with the names you were already using. poj showed you how to do something similar with more basic hash references. but if you didnt understand the difference between  my $unjson=$jason->... , and my @unjson=$json-> i doubted you would understand that that is doing.

    So yes i doubted you ability to understand what you were trying to do, and yes i doubted your ability to implement more complex LWP or CSV calls, and i didnt think you would have a clue about what the $base loop was doing. I was hoping it might press you to learn about references to understand the code i had presented.

    And yes, i was pissed that you lied to us when you posted things as a fact that you knew were not true. You did not even take the time to add a print $api_results."\n"; and cut and paste the output to us, instead taking shortcuts that did not present what you said they did.

    And yes, you were complaining about error messages you did not seem to try to have put any effort into figuring out for yourself before coming to us for help. Just like others who come here just wanting only a solution rather than any knowledge.

    Hail, after die $dbh->errst$ i doubted your ability to even cut&paste.

    Yet rather than blow you off, i still put effort into presenting a solution, while pointing out places i felt you had disrespected what the monks are trying to do here.

    Yet you want to paint me as the "bad guy" in this? Or is it because you knew i was right about all of this that you are are trying to save face by barking back at me ? I think the answer is clear. Well nobody is going to accuse you of not having chutzpah