Cannot use like operator on optional column

[Playrom]

Description

If a column is defined as optional string, the like operator cannot be used

Checklist

• I have determined whether this bug is also reproducible in a vanilla SwiftUI project.
• If possible, I've reproduced the issue using the main branch of this package.
• This issue hasn't been addressed in an existing GitHub issue or discussion.

Expected behavior

A snippet like the following should compile

@Table
struct Tab: Sendable {
    let id: Int
    let name: String?
}

struct Foo:View {
    @FetchAll(
        Tab.all
        .where {
            $0.name.like("%test%")
        }
        .select {
            $0.id
        }
    )
    var tabs

    var body: some View { EmptyView() }
}

Actual behavior

the operator like is defined to have a QueryExpression as LHS generic, and the sugarcoted like function is defined only on this extension

extension QueryExpression where QueryValue == String {

Normally for a operator to be available for column with a Wrapped optional it should be defined in another extension additionally to the not optional one

It is a perfectly valid QUERY string to provide a not "String" expression as LHS part of a LIKE operator, so the LHS requirement may be dropped, and other swift extension function may be provided

Reproducing project

No response

Structured Queries version information

0.21

Destination operating system

No response

Xcode version information

No response

Swift Compiler version information

[Playrom]

If the LHS String requirement is to be dropped, I already have an extension that may work

extension QueryExpression where QueryValue: QueryBindable & _OptionalProtocol, QueryValue.Wrapped == String {
    @_documentation(visibility: private)
    public func like(
      _ pattern: some StringProtocol,
      escape: Character? = nil
    ) -> some QueryExpression<Bool> {
        LikeOperator(
            string: self,
            pattern: "\(pattern)",
            escape: escape
        )
    }

    @_documentation(visibility: private)
    public func hasPrefix(_ other: some StringProtocol) -> some QueryExpression<Bool> {
      like("\(other)%")
    }

    @_documentation(visibility: private)
    public func hasSuffix(_ other: some StringProtocol) -> some QueryExpression<Bool> {
      like("%\(other)")
    }

    @_disfavoredOverload
    @_documentation(visibility: private)
    public func contains(_ other: some StringProtocol) -> some QueryExpression<Bool> {
      like("%\(other)%")
    }
}

[Playrom]

I've seen this PR , #80 , I think that then this is not a bug, but something that is designed this way? But honestly I don't understand why map/flatMap should be more ergonomic than directly calling a "like function"

[stephencelis]

@Playrom While NULL LIKE '%blob%' is completely valid SQL, it also evaluates to NULL, not 0, and so it would fail to decode if you were to select it directly, so your overloads should probably return some QueryExpression<Bool?>. These overloads could quickly spiral out of control, so we prefer a more reusable solution. If map is strange to you:

$0.name.map { $0.like("%test%") }

You could also coalesce to an empty string:

($0.name ?? "").like("%test%")

Since this isn't a bug I'm going to convert to a discussion. Let us know what you think!

[mbrandonw]

I was typing a response when @stephencelis replied and he said everything I was gonna say, but just to spell out the selection problem he mentioned, consider this:

@Selection struct Row {
  let tab: Tab
  let isTest: Bool
}

Tab.select {
  Row.Columns(
    tab: $0,
    isTest: $0.name.like("test")
  )
}

If we allowed like to be defined on optional strings and used it like above, then this query would fail to decode into the Row type for Tabs that have a nil name. You would have to know to actually represent Row as:

@Selection struct Row {
  let tab: Tab
  let isTest: Bool?  // <- Optional boolean!
}

And so that's why we feel that being explicit with optionality is best.

[Playrom]

ye, I understand your reason! great work

I only think that map/flatMap is a bit "obscure" , needs more documentation, because I think that using optional is a common pattern!