Bug 12349 – JSON communication over cometd changed in 7.4 SQLite builds

Bug 12349 - JSON communication over cometd changed in 7.4 SQLite builds

Summary:

JSON communication over cometd changed in 7.4 SQLite builds

Status:	CLOSED WORKSFORME

Product:	Logitech Media Server
Classification:	Unclassified
Component:	CLI
Version:	7.4.0
Platform:	All All

Importance:	P1 normal (vote)
Target Milestone:	7.6.0
Assigned To:	Andy Grundman

URL:
Keywords:	ipeng, SQLite

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2009-06-11 12:42 UTC by Joerg Schwieder
Modified:	2011-05-23 09:21 UTC (History)
CC List:	2 users (show)

See Also:
Category:	---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Joerg Schwieder 2009-06-11 12:42:58 UTC

I've currently got an issue with the 7.4 SQLite builds of SC and iPeng.
The JSON encoding over cometd changed for item IDs. IDs are either a string (for URLs) or a number (for DB IDs). Up until 7.4 MySQL builds these IDs were always transmitted as a string (that is: numbers had quotes areound them as in "20" as opposed to 20).
Now they are numbers.
While this is a small change it breaks the current iPeng distribution version on the App Store.
I do have a fix, yet if it's not an intentional change it may be worthwhile to change it back to the old behavior to keep iPeng working with 7.4 beta

Comment 1 Andy Grundman 2009-06-11 12:51:57 UTC

Must be related to the latest JSON::XS version being used.

Comment 2 Joerg Schwieder 2009-06-11 12:53:29 UTC

Any chance to change it?

Comment 3 Andy Grundman 2009-06-11 15:35:27 UTC

Give change 27032 a try, let me know if there are more cases where it happens.

Comment 4 Andy Grundman 2011-01-12 12:08:28 UTC

SQLite bugs need to go back to 7.6 target.

Comment 5 Joerg Schwieder 2011-01-12 17:36:01 UTC

No idea, iPeng is now safe against wrong types all over the place.

I believe it still happens a lot, I especially see a lot of "text" fields that actually use a numeric encoding if the content of the text field is a number which will confuse any strict JSON parser.

I believe the original request (DB IDs) is no longer an issue (and never has been since the 7.4 release) because the IDs have switched to string IDs anyway...