Skip to content

Conversation

@theganyo
Copy link
Member

This is a quick proof of concept for storing labels as JSON and allowing our CEL filters to use SQL. An actual implementation would handle more cases and include a fallback process for filters that can't be properly converted.

@theganyo theganyo requested a review from timburks August 15, 2023 19:15
@theganyo
Copy link
Member Author

JFYI, the failing tests are because of a couple of CEL conversion failures:

@theganyo
Copy link
Member Author

For posterity, if we return to this we may also want to look at indexing the JSON. Some references:

RecommendedDeployment string // Recommended API deployment.
Labels []byte // Serialized labels.
Annotations []byte // Serialized annotations.
Labels datatypes.JSON
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know what this is using at the database level? I'm guessing/hoping json or jsonb for Postgres, but have no idea what it's doing for SQLite (bytes?).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SQLite natively supports JSON and GORM creates this as a JSON type column.

return Filter{}, status.Error(codes.InvalidArgument, err.Error())
}
// TODO: quick hack to adjust field name
sqlCondition = strings.ReplaceAll(sqlCondition, "name", "key")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow, I'm amazed that cel2sql.Convert() works with so little modification. I was thinking that we would have to own this parsing/conversion. I expect it will at least need to be a grey box to us (if we use it, we'll at least be stepping inside it to understand/debug it)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eh... well, it "works" for simple cases. It's not complete and it's created specifically for Big Query, so most likely we'll have to fork... and even then, as I mentioned, I think we'll have to have a fallback path for some CEL.

Copy link
Contributor

@timburks timburks Aug 16, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I just read the comment about the failing tests, that's in line with this)

Copy link
Contributor

@timburks timburks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Impressive - do you see an easy way to structure this to be optional? That looks difficult with the gorm annotations on our table structures, but it would be nice to have this behind a feature flag. If we can't do that, we might want to start an experimental branch to take this further.

@theganyo
Copy link
Member Author

do you see an easy way to structure this to be optional

Not for the data, but I'm not sure that's necessary... it should be easy to move from binary blob to JSON and change nothing but the encoding and decoding.

As for switching between SQL/CEL and CEL-only? Yes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Inbox

Development

Successfully merging this pull request may close these issues.

2 participants