Allow querying if an @OptionalField "IS NOT NULL" without fetching it

[Torgen]

Please summarize your feature request

Some way of fetching "x IS NOT NULL" without fetching X

Describe the functionality you're seeking in more detail

If I have an optional blob, I may want to know whether it is null (so I can only show a link to download it if it exists) without fetching it from the database (because I'm not doing anything else with it right now and I'd like to put less load on the database). This could be implemented as a property wrapper you can attach to a boolean to identify it as the presence of another field, or as a property of the @OptionalField property wrapper so you can fetch e.g. \.$optional\.$present to fetch the presence but not the field itself.

Have you considered any alternatives?

Could store my own boolean containing whether I set the optional field, but I would have to keep it consistent myself.

[0xTim]

@Torgen I'm not clear on what you're asking for here - do you want to know if the field has been retrieved by Fluent or are you looking for something that tracks model changes so you don't need to go to the database for the latest changes?

[Torgen]

Imagine the query:

select x IS NOT NULL as x_presence from model where id = 'something';

That doesn't transfer X to the client, which matters because X might be very large.

I want some way of telling Fluent to do that query and store that result somewhere in the returned model object(s).

[0xTim]

Fluent doesn't support subqueries or returning anything other than a model. I think you'll probably need to drop down to SQLKit to do what you want

[Torgen]

I was thinking this could work like Siblings, where you can .with the pivots instead of the siblings themselves and access them through a field on the property wrapper. Like maybe add an exists field to OptionalChild, and if you want to fetch it but not the child itself you put .with(\.$child.$exists) in your query and access the presence via parent.$child.exists. That does mean moving the blobs to a child table instead of storing them directly in the parent table, but that seems benign.

[0xTim]

You can definitely treat the pivots as a regular relation and use the normal helpers for that. Adding extra fields is unlikely to happen at this stage of Fluent's lifecycle