You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 28, 2021. It is now read-only.
Repository navigation
This repository was archived by the owner on Jan 28, 2021. It is now read-only.
FR: Select single fields from substring search or split results #747
I would like to be able to split a string and select one of the fields. The SPLIT function returns a JSON array, so I can't use that directly. There is a SUBSTRING function, but there does not appear to be any way to find the offset of a partition (what MySQL calls LOCATE or POSITION).
One way to address this would be to give SPLIT an optional third parameter, so that
The first is probably better, since LOCATE would probably want a "skip" parameter anyway to specify which of the matches to stop on. But the second would also work.
@ajnavarro Since we have JSON_EXTRACT, I see no urgency to implement SUBSTRING_INDEX, but we should still consider it when it comes to align a subset of functions between gitbase and Spark SQL. That is, those functions we want to be able to push down from Spark SQL.
I have run into another case where JSON_EXTRACT can be a little limiting. Suppose I would like to identify branch points, that is to say, commits that have multiple children. This is not that interesting in a single repo, but is a useful basis for finding places where forks happened and diverged across multiple repos.
The obvious way to do this is to do an autojoin on commits, but commit_parents is multi-valued. You can filter by length with ARRAY_LENGTH, but JSON_EXTRACT projects the literal string value including its quotes, so you can't join on it without doing extra string surgery.
I could write a program, but it seems unfortunate that we don't have a good way to get properly-typed values out of these denormalized fields. Arguably this is better solved with a schema change, but that's probably a lot more work (and maybe not worth it—this problem is mostly a demonstration case for me, not a blocking work item).
Anyway, just another datum on that while I'm working with it.
Activity
smola commentedon Apr 10, 2019
We could implement
SUBSTRING_INDEX, which is supported both in MySQL and Spark SQL.It would be:
For second part, it's a quite verbose but still possible:
ajnavarro commentedon Apr 10, 2019
@creachadair Right now you can use
JSON_EXTRACTto get the value of a specific position:@smola having this implemented is it worth it implement
SUBSTRING_INDEX?smola commentedon Apr 10, 2019
@ajnavarro Since we have
JSON_EXTRACT, I see no urgency to implementSUBSTRING_INDEX, but we should still consider it when it comes to align a subset of functions between gitbase and Spark SQL. That is, those functions we want to be able to push down from Spark SQL.creachadair commentedon Apr 15, 2019
I have run into another case where
JSON_EXTRACTcan be a little limiting. Suppose I would like to identify branch points, that is to say, commits that have multiple children. This is not that interesting in a single repo, but is a useful basis for finding places where forks happened and diverged across multiple repos.The obvious way to do this is to do an autojoin on
commits, butcommit_parentsis multi-valued. You can filter by length withARRAY_LENGTH, butJSON_EXTRACTprojects the literal string value including its quotes, so you can't join on it without doing extra string surgery.I could write a program, but it seems unfortunate that we don't have a good way to get properly-typed values out of these denormalized fields. Arguably this is better solved with a schema change, but that's probably a lot more work (and maybe not worth it—this problem is mostly a demonstration case for me, not a blocking work item).
Anyway, just another datum on that while I'm working with it.
ajnavarro commentedon Apr 16, 2019
maybe implementing JSON inline selectors: https://dev.mysql.com/doc/refman/8.0/en/json-search-functions.html#operator_json-inline-path or just
JSON_UNQUOTEat the beginning we can fix that problem and many others.