Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feed names' case-sensitive during publish #123

Closed
phord opened this issue Jun 5, 2020 · 1 comment
Closed

Feed names' case-sensitive during publish #123

phord opened this issue Jun 5, 2020 · 1 comment

Comments

@phord
Copy link
Contributor

phord commented Jun 5, 2020

The docs say the feednames are case-insensitive, but the code in AdafruitIO_Group::getFeed searches for the feednames using case-sensitive strcmp. This means I could get unexpected results if I publish to "FOO" and to "foo" in the same message. This weird different-case scenario also happens if IO messages are showing up in my group feed as in #122 as well.

phord added a commit to phord/Adafruit_IO_Arduino that referenced this issue Jun 6, 2020
Feeds are matched with a case-sensitive search when adding new feed
data to a Group.  This can cause different values to be published
for the same feed in a single call to save() in a way that's not
easy to see from the code.

Avoid the problem by matching feeds case-insensitively when searching
for existing feeds in the Group data list.

Note: I added the new `strcmp_nocase` function inline in the
AdafruitIO_Group.cpp module since I didn't see any clear place to put
these kinds of utility functions in the library.  I'm open to moving
it, renaming, restructuring it or whatever.  Perhaps a better option
is to use the `String::equalsIgnoreCase()`, but constructing String
temporaries for each comparison seemed excessive to me.

Fixes adafruit#123
phord added a commit to phord/Adafruit_IO_Arduino that referenced this issue Jun 6, 2020
Feeds are matched with a case-sensitive search when adding new feed
data to a Group.  This can cause different values to be published
for the same feed in a single call to save() in a way that's not
easy to see from the code.

Avoid the problem by matching feeds case-insensitively when searching
for existing feeds in the Group data list.

Note: I added the new `strcmp_nocase` function inline in the
AdafruitIO_Group.cpp module since I didn't see any clear place to put
these kinds of utility functions in the library.  I'm open to moving
it, renaming, restructuring it or whatever.  Perhaps a better option
is to use the `String::equalsIgnoreCase()`, but constructing String
temporaries for each comparison seemed excessive to me.

Fixes adafruit#123
phord added a commit to phord/Adafruit_IO_Arduino that referenced this issue Jun 6, 2020
Feeds are matched with a case-sensitive search when adding new feed
data to a Group.  This can cause different values to be published
for the same feed in a single call to save() in a way that's not
easy to see from the code.

Also, subscribing to a feed using the uppercase name of the feed
will never work since the feed names are lowercased when received
from AdafruitIO but the string compare here is strictly
case-sensitive.

Fix these problems by matching feed names case-insensitively when
searching for existing feeds in the Group data list and when matching
callback lookups.

Note: I added the new `strsame_nocase` function inline in the
AdafruitIO_Group.cpp module since I didn't see any clear place to put
these kinds of utility functions in the library.  I'm open to moving
it, renaming, restructuring it or whatever.  Perhaps a better option
is to use the `String::equalsIgnoreCase()`, but constructing String
temporaries for each comparison seemed excessive to me.

Fixes adafruit#123
@phord
Copy link
Contributor Author

phord commented Jun 7, 2020

After reading this article about naming things I can see I am confusing feed names and feed keys.

Maybe my real problem is just that #122 is causing my Group data list to be populated with key-names where I am expecting feed-names.

Let me close this while I try to sort out what's really expected here.

@phord phord closed this as completed Jun 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant