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

Is SQL syntax support with Kuksa.Val.x version deprecation is permanent? #133

Open
venkatkonjeti-cariad opened this issue Feb 4, 2025 · 2 comments
Labels
question Further information is requested

Comments

@venkatkonjeti-cariad
Copy link

venkatkonjeti-cariad commented Feb 4, 2025

The SQL syntax documented on this page https://github.com/eclipse-kuksa/kuksa-databroker/blob/main/doc/QUERY.md says it is only relevant for the sdv.databroker.v1. Was it discontinued in the kuksa.val.v1 and above versions? If yes, the alternate is documented as shown in the python sdk here? https://github.com/eclipse-kuksa/kuksa-python-sdk/blob/main/docs/examples/async-grpc.md

SQL syntax is more friendly, was there a reason to deprecate the support?

I appreciate any insights on this.

Thanks
Venkat

@venkatkonjeti-cariad venkatkonjeti-cariad changed the title Is Is SQL syntax support with Kuksa.Val.x version deprecation is permanent? Feb 4, 2025
@mikehaller
Copy link
Contributor

Due to a finding in a security audit, the SQL syntax was permanently disabled for SDV V1. The API is by default disabled, but will be kept for some time onwards. There are no known plans yet to re-add the feature to newer APIs.

Contributions welcome, however we'd like to have a secure design and implementation and generic SQL-like syntaxes are a bit more complicated and take more effort to make them right. Hence, we decided that for production use-cases, it's of lower priority and we can postpone it to future releases.

Do you have a specific use cases in mind which goes beyond the obvious and usual developer convenience (not saying that is unimportant, just that we're aware of it).

@lukasmittag lukasmittag added the question Further information is requested label Feb 6, 2025
@venkatkonjeti-cariad
Copy link
Author

Thanks @mikehaller for the details.

The use case we are trying was, subscribe for telemetry based on filters, so that we can receive telemetry only condition matches. Also, managing these rules through an external file avoids need to deploy the code again. We felt SQL is string so replacing this dynamically going to handy.

Example just for demonstration:

  • vehicle.speed > 50
  • Fan.speed > 3

Scenarios:

  • Update existing signal subscription vehicle.speed > 80
  • Adding new signal to subscribe Door.Row3.Left.Window.Position

Adding and updates to subscription wanted to enable without deployments if there is an option.

Please let me know if you have any thoughts on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants