11th Step Meetings encoded incorrectly when imported via csv file

[crispyatl]

In short, when you add a meeting through the web interface, the 11th Step Meeting code is stored as a string, but when you import it from a csv, it is stored as an int. This explains why only certain sites are affected by the issue: It occurs in the very specific corner case that an 11th Step Meeting is imported from a csv file.

This is the root cause of related issue #257. While PR #267 is now available to work around the issue, arguably the code that loads the csv should also be fixed.

If you add an 11th Step Meditation meeting in the web interface, it looks like this in the DB:

mysql> select meta_value from wp_postmeta where meta_id = 31737;
+---------------------------------+
| meta_value                      |
+---------------------------------+
| a:2:{i:0;s:1:"O";i:1;s:2:"11";} |
+---------------------------------+
1 row in set (0.00 sec)

However, if you import an 11th Step Meditation meeting from a csv file, it looks like this:

mysql> select meta_value from wp_postmeta where meta_id = 31763;
+-----------------------------+
| meta_value                  |
+-----------------------------+
| a:2:{i:0;s:1:"O";i:1;i:11;} |
+-----------------------------+
1 row in set (0.00 sec)

[joshreisner]

I do see that if I create a meeting with 11th Step Meditation it is a string and if I import it from CSV it is an int, but it still shows up for me fine in the backend and in the frontend.

What is the negative effect other than the appearance of the record in SQL?

a:3:{i:0;s:2:"11";i:1;s:1:"P";i:2;s:3:"ONL";}

vs

a:3:{i:0;i:11;i:1;s:1:"P";i:2;s:3:"ONL";}

[apresence]

Some of the code use to throw an exception due to the datatype change. I fixed that part. So the remaining issue with it switching types is just one of consistency. You can't trust code that's manipulation your data to handle varying data types. So, up to you if it's worth fixing or not. Thanks! Sent from my Verizon, Samsung Galaxy smartphone

…

-------- Original message -------- From: Josh Reisner ***@***.***> Date: 10/16/21 12:54 PM (GMT-05:00) To: code4recovery/12-step-meeting-list ***@***.***> Cc: apresence ***@***.***>, Comment ***@***.***> Subject: Re: [code4recovery/12-step-meeting-list] 11th Step Meetings encoded incorrectly when imported via csv file (#268) I do see that if I create a meeting with 11th Step Meditation it is a string and if I import it from CSV it is an int, but it still shows up for me fine in the backend and in the frontend. What is the negative effect other than the appearance of the record in SQL? a:3:{i:0;s:2:"11";i:1;s:1:"P";i:2;s:3:"ONL";} vs a:3:{i:0;i:11;i:1;s:1:"P";i:2;s:3:"ONL";} — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#268 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AB5EQDSJWWFNUQMBLFAJFSLUHGU4NANCNFSM4WF3DRRQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[joshreisner]

i'm going to close this - i feel like unless we get a report from the field that this caused an error that it isn't worth making an automated SQL update