Property values containing space characters

[dxmaxwell]

@archman was testing CF/RecSync and found a problem when querying the 'time' property.

If the time property has a value of '2016-12-11 14:02:36.12422'

Then this query will find the expected channels:

.../channels?time=2016-12-11*

But this query will find nothing:

.../channels?time=2016-12-11 14*

The problem appears to be related to the space character and remains even if it's properly URL encoded with %20.

[shroffk]

All properties are string key value pairs, with no support spaces. The spaces are currently being added by the recsync module, I will add an update to ensure that the recsync module does not include spaces.

Should we have the service reject these properties too +1 from me

[dxmaxwell]

Yes, rejecting unsupported values makes sense to me.

[shroffk]

Well technically they are not "unsupported" You can think of them as a multi value property,

Device=BPM C01

now when you query for Device=BPM or Device=C01, you will get that channel. Thus you can have a channel with a property with multiple values

[shroffk]

In the above case if you search time=2016-12-11 you will get the appropriate list of channels time=14:02:36.12422 will also return the list of channels

[dxmaxwell]

Thanks for the clarification. I can see how this could be a useful feature, but to me it is completely unintuitive. I think we should reject property values with spaces. If there is a need in the future, perhaps we could reintroduce it with a more deliberate design. For instance, maybe using a different delimiter than space for multiple property values.

[dxmaxwell]

@berryma4 thinks this would be a good feature to keep.

[berryma4]

So, here is my use case. In DB files we would like to have: info("archive", "field1 field2 field3")

Because it follows what other info arrays are doing.

So, if we keep this, I have something that already works :1st_place_medal:

[shroffk]

The more I think about this, the more I like it too... I can add more documentation