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

Property values containing space characters #19

Open
dxmaxwell opened this issue Jan 3, 2017 · 8 comments
Open

Property values containing space characters #19

dxmaxwell opened this issue Jan 3, 2017 · 8 comments

Comments

@dxmaxwell
Copy link

@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
Copy link
Contributor

shroffk commented Jan 3, 2017

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
Copy link
Author

Yes, rejecting unsupported values makes sense to me.

@shroffk
Copy link
Contributor

shroffk commented Jan 3, 2017

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
Copy link
Contributor

shroffk commented Jan 3, 2017

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
Copy link
Author

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
Copy link
Author

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

@berryma4
Copy link
Contributor

berryma4 commented Jan 5, 2017

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 🥇

@shroffk
Copy link
Contributor

shroffk commented Jan 5, 2017

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

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

No branches or pull requests

3 participants