Skip to content

Fix Bug 4169#4171

Merged
jeremydmiller merged 6 commits intoJasperFx:masterfrom
Blackclaws:fix/bug-4169
Mar 12, 2026
Merged

Fix Bug 4169#4171
jeremydmiller merged 6 commits intoJasperFx:masterfrom
Blackclaws:fix/bug-4169

Conversation

@Blackclaws
Copy link
Contributor

Fixed #4169 and related issues.

Co-authored with Claude Code - Opus 4.6

Verified existing tests still pass.

Note: This changes existing behaviour by fixing a bug where a % or _ in StartsWith, EndsWith and Contains is now no longer treated as a Wildcard. If people were relying on this behavior this might be breaking for them. This would however be relying on undocumented and unexpected behaviour. Just wanted to mention it.

Blackclaws and others added 6 commits March 12, 2026 15:41
…als on ILIKE wildcards (JasperFx#4169)

Co-Authored-By: Claude <noreply@anthropic.com>
…n ILIKE wildcards (JasperFx#4169)

StringEqualsIgnoreCaseFilter now implements ICompiledQueryAwareFilter so
parameter matching uses the raw value and ILIKE escaping is deferred to
runtime in the generated code.

Closes JasperFx#4169
Co-Authored-By: Claude <noreply@anthropic.com>
…/StartsWith/EndsWith (JasperFx#4169)

Co-Authored-By: Claude <noreply@anthropic.com>
…h/EndsWith helpers (JasperFx#4169)

The ContainsString(), StartsWith(), and EndsWith() helpers in compiled
query base classes were not escaping %, _, and \ before wrapping with
LIKE wildcards, causing user values containing those characters to be
treated as SQL wildcards at runtime.

Co-Authored-By: Claude <noreply@anthropic.com>
…ery (JasperFx#4169)

Compiled queries using Select projections hit StatelessCompiledQuery
which has StartsWith and EndsWith helpers swapped, causing prefix
matches to behave as suffix matches and vice versa.

Co-Authored-By: Claude <noreply@anthropic.com>
… and ComplexCompiledQuery (JasperFx#4169)

StartsWith() returned a suffix pattern (%value) and EndsWith() returned
a prefix pattern (value%) in both classes, causing compiled queries with
Select projections or Includes to match the wrong end of the string.

Co-Authored-By: Claude <noreply@anthropic.com>
@Blackclaws
Copy link
Contributor Author

Test failures look to be either preexisting or flaky test for the single timing related one, but do double check on your side. Tests pass locally for me.

@jeremydmiller
Copy link
Member

The LINQ failure is not related, I've got this from here

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

Successfully merging this pull request may close these issues.

[Bug] Compiled query with case-insensitive string.Equals fails with CS1009 when initial compilation value contains %, _, or \

2 participants