Update filter query to support camel case for certain fields#14
Update filter query to support camel case for certain fields#14
Conversation
…istency with lupo
📝 WalkthroughWalkthroughAdds package-level camelCase→snake_case field translation maps and applies direct and regex-based rewrites to input query strings inside buildQueryString, using imported regexp and strings packages before building the final query_string payload. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@opensearch.go`:
- Line 34: The global replacement mapping currently includes the entry `"/" →
"\\/"`, which over-broadly escapes all forward slashes and can corrupt values
like DOIs or URLs; remove that entry from the camelCase→snake_case transform map
and instead implement a separate, well-documented transformation (e.g. an
`escapeSlashesInQuery` step) that is applied only where needed; scope this new
step narrowly — call it from the query-building code that injects literal query
text and limit it to locations outside quoted terms or to specific value
positions (or provide an option/flag) so values (like `doi:10.1234/foo`) are
preserved; add a clear comment explaining why and when slashes are escaped.
🧹 Nitpick comments (1)
opensearch.go (1)
86-92: Go map iteration order is non-deterministic — currently safe but fragile.Go randomizes map iteration order. Right now the replacement keys don't overlap, so this is fine. But if future entries introduce overlapping keys or regexes (e.g., a key that is a substring of another key's replacement), results could become non-deterministic. A slice of ordered pairs would be more robust.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@opensearch.go`:
- Around line 86-88: The current loop over camelCaseToSnakeCaseFields is
nondeterministic because Go maps iterate in random order, so perform
replacements in a deterministic sequence: replace the map with an ordered slice
of pairs (e.g., []struct{from,to string}) and iterate that slice when updating
query, or at minimum remove the "/"→"\\/" entry from camelCaseToSnakeCaseFields
and apply the slash-escaping as a separate deterministic step (e.g., call
strings.ReplaceAll(query, "/", "\\/") before or after the ordered field-name
replacements). Update references to camelCaseToSnakeCaseFields and the
replacement loop accordingly so replacements of field names and the "/" escaping
happen in a fixed, predictable order.
🧹 Nitpick comments (1)
opensearch.go (1)
90-92: Pre-compile regexps at package level instead of on every call.
regexp.MustCompileis called inside the loop on every invocation ofbuildQueryString. Compile once at init time to avoid redundant work per request.♻️ Proposed fix
Replace the string-keyed regex map with pre-compiled regexps:
-var camelCaseToSnakeCaseFieldsRegex = map[string]string{ - `(publisher\.)(name|publisherIdentifier|publisherIdentifierScheme|schemeUri|lang)`: "publisher_obj.$2", -} +var camelCaseToSnakeCaseFieldsRegex = map[*regexp.Regexp]string{ + regexp.MustCompile(`(publisher\.)(name|publisherIdentifier|publisherIdentifierScheme|schemeUri|lang)`): "publisher_obj.$2", +}Then in
buildQueryString:for regex, field := range camelCaseToSnakeCaseFieldsRegex { - query = regexp.MustCompile(regex).ReplaceAllString(query, field) + query = regex.ReplaceAllString(query, field) }
1 participant
Purpose
closes: #10
Approach
Implements lupo's camel-case to snake-case replacement in Go.
Open Questions and Pre-Merge TODOs
Learning
Types of changes
Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Reviewer, please remember our guidelines:
Summary by CodeRabbit