orm: add function call api

[kbkpbot]

Feature Request #24178

[kbkpbot]

The code call panic everywhere, but if not, the chain function call will be horrible.

qb.where('userid > ?', 123)!.query()!

...

[Avey777]

Looking forward to this merger.

[Avey777]

@medvednikov
You seem to have said that you also need dynamic filtering of orm. Check this out

[medvednikov]

You're a machine! Great job :)

[medvednikov]

@spytheman @felipensp what do you think?

[felipensp]

@spytheman @felipensp what do you think?

Nice work @kbkpbot! Looks a great addition. I just don't like mixing different statements via chaining calls.

[Avey777]

Nice work@mindplay-dk
You seem to have said that you also need dynamic filtering of orm. Check this out

I want to know. Which of the PR grammar and the existing ORM grammar will be retained in the end?Give us directions for future use.

[spytheman]

The code call panic everywhere, but if not, the chain function call will be horrible.

Panics can not be intercepted by the callers, while returned errors can.

[spytheman]

I want to know. Which of the PR grammar and the existing ORM grammar will be retained in the end?Give us directions for future use.

The use cases are different - a static query, made with the ORM syntax, can be analyzed by the compiler, and you can get an error right away, if you mess up something.

A dynamic query can not be analyzed statically, and so you will get an error at runtime, but only if you execute that piece of code, written using the query builder.

If you look at it from that perspective, imho it is pretty clear what you should prefer.

[spytheman]

@spytheman @felipensp what do you think?

I think it is a very good compromise (except of using panics instead of returning errors, since while that may make the call sites a bit more verbose, because of the ! signs, it also makes them free to decide for themselves how to handle the potential runtime errors, not just panic and exit the entire program).

It gives an additional freedom and convenience, to people that want to construct dynamic queries at runtime, without having to drop to the underlying driver specific APIs. At the same time, it does it without having to modify the language itself, using an API that is more or less convenient, and checked by the compiler as much as possible, which is also nice.

[Avey777]

I want to know. Which of the PR grammar and the existing ORM grammar will be retained in the end?Give us directions for future use.

The use cases are different - a static query, made with the ORM syntax, can be analyzed by the compiler, and you can get an error right away, if you mess up something.

A dynamic query can not be analyzed statically, and so you will get an error at runtime, but only if you execute that piece of code, written using the query builder.

If you look at it from that perspective, imho it is pretty clear what you should prefer.

Ok, I think I know how to adjust my code after this pr merge

[kbkpbot]

I wonder can the error ! be propagated along a chain of function calls, so that only the last function in the chain needs a single !?

before :

x := gb.where(...)!
           .where(...)!
           .where(...)!
           .where(...)!
           .where(...)!
           .where(...)!
           .query()!

after:

x := gb.where(...)
           .where(...)
           .where(...)
           .where(...)
           .where(...)
           .where(...)
           .query()!