General discussion on the "services/caches/save_personal_note" method.

[GoogleCodeExporter]

General discussion on the "services/caches/save_personal_note" method.

Original issue reported on code.google.com by rygielski on 25 Jan 2014 at 10:05

[pstorch]

Is there any size limit on new_value?
I was able to upload 4416873 bytes of Text. Didn't test any further ;)

[wrygiel]

This depends on OC installation. Whatever you upload, OKAPI will attempt to insert into the appropriate database field. However, OKAPI doesn't check if there's any limit on the database field. If there is, then I guess that MySQL will silently truncate your string at certain length.

I just checked different OC database structures and it seems that OCPL will truncate your data at 64kB, while OCDE will allow 16MB.

[pstorch]

The reason behind my question is a c:geo issue: cgeo/cgeo#6591
So I guess if we implement a 64kB Limit for OKAPI based Caches, we are on the safe side?

[wrygiel]

Yes, I think so. BTW, you will probably need to take into account that some UTF8 characters can eat much more than one byte.

[pstorch]

@wrygiel good point

[wrygiel]

Depending on the charset used to store the data, all characters (even those from BMP) can eat more than one byte. As far as I can recall, MySQL uses 2 or 3 bytes per each character. So, it might be the safest to limit this to ~20k characters.

[wrygiel]

Added a link in cc7f9a7.

[hxdimpf]

I believe the service isn't working as intended. Here is my test:

• Startcondition, a cache with zero text in the cache note
• my first request: https://www.opencaching.de/okapi/services/caches/save_personal_notes?cache_code=OC17BD&old_value=&new_value=Test
• Response: {"saved_value": "Test", "replaced": true} ... which is absolutely what I had expected
• Next request, assuming that an empty old_value and an empty new_value will actually delete what's in the database, effectively make the personal note empty: https://www.opencaching.de/okapi/services/caches/save_personal_notes?cache_code=OC17BD&old_value=&new_value=
• Response: {"saved_value": "Test\n\n", "replaced": false} ... first of all, the \n\n is totally unexpected, second, I had expected to get {saved_value": "", "replaced":true}
• Final test: knowing that Test\n\n is out there, trying to clear it: https://www.opencaching.de/okapi/services/caches/save_personal_notes?cache_code=OC17BD&old_value=Test\n\n&new_value=
• Result: { "saved_value": "Test\n\n", "replaced": false} .. Remember, I had exactly passed the correct old_value

With all that experience, I would highly recommend to implement a parameter or option that makes the service unconditionally write new_value completely replacing what was potentially there. It is within the discretion of the client application to know what it wants to write to the personal cache notes. I don't know of any use case where one wants to add text to what's already out there. This is not an idempotent operation.

[wrygiel]

Next request, assuming that an empty old_value and an empty new_value will actually delete what's in the database

It should. But in your case you have just set the value to "Test", so it's no longer empty. I'd try old_value=Test&new_value= instead.

The \n\n is totally unexpected

It's not explicitly documented, but appending is done with a \n\n separator. So, if the client doesn't have access to old_value, then <old_value>\n\n<new_value> will be stored (two separate messages).

Final test: knowing that Test\n\n is out there, trying to clear it

Newlines are formatted as \n in JSON, but input variables (the ones you use in the URL) are not JSON-encoded. Try URL-encoding your values before using them in inputs.

[hxdimpf]

Ok, it is what it is. "works as designed". I can live with it but I have a hard time to understand the rationales for designing it that way. I'd want an "idempotent setter", for instance a semantics like this:

myPCN = getPersonalCacheNote(cache_code)

and an idempotent operation:

setPersonalCacheNote(cache_code, myPCN)