How to implement "native-parameters" feature for a custom plugin

Hello,

I’m trying to evaluate the viability of developing a custom plugin for my company. One of our main needs is to have the “native-parameters” feature available for our plugin.

After quickly scanning through the multimethods available in the driver.clj, I’m lost in regards to which multimethod is called to parse the “native query” that contains the special syntax for substituting the native-parameters.

Is the unparsed “native query” sent to the execute-query multimethod, or to the mbql->native multimethod? If neither of these two, then where else is the unparsed “native-query” substituted with the parameters’ values?

Hi @JohnnyMarc
So you’re looking into creating a new driver or am I misunderstanding your question? If driver, which?
There was a major overhaul of the substitution a few days ago, but every should be located here:
https://github.com/metabase/metabase/tree/master/src/metabase/query_processor/middleware/parameters

Hi @flamber ,

Yes, I’m looking to implement a custom driver.

After reading the documentation from that link, I see that the parsing and substitution is done through a middleware before it reaches the driver’s implementations of the multimethods, if I’m understanding correctly. Please do correct me if I’m wrong.

I think this answers my question, and I believe I can make it work for my use case. Thanks a lot for the help.

Out of topic: Wouldn’t it be quite useful if, instead, the work of substituting in the variables in the native query is delegated to the drivers’ implementations? After all, a driver’s native queries may use a different syntax that would be incompatible with the syntax used for defining the parameters within the query.

@JohnnyMarc
Which driver? There are a bunch of third-party drivers already, so just trying to avoid you starting from a clean slate.

As far as I understand, yes that’s correct.

As for having the variable substitution as part of the driver - or at least a more flexible solution - would be a good idea.
This is the reason why example MongoDB doesn’t have variables:
https://github.com/metabase/metabase/issues/3653
Note that it has milestone 0.34 (not a guarantee through), so maybe there will be more options in the future.

@flamber

It is for a custom datastore used in my company. I can’t give out more details, sorry :frowning: .

I’m really interested in the possibility of delegating the substitution work to drivers, it would make Metabase much more extensible for developers with use cases like mine. Would you find this as a reasonable feature request sometime in the future?

@JohnnyMarc
If the custom datastore is based on something (which I guess it is), then you might get a running start if you find similar drivers to start your work from.

Until MongoDB variables has been implemented, then I’m not sure how the substitution would be, but it sounds like a reasonable request.
If/when you open a request, please post the link here.

I would recommend that you subscribe to notifications on this issue, since it contains good hints and links:
https://github.com/metabase/metabase/issues/9348

There’s also this issue, which is caused by how variables are currently handled (as far as I can tell):
https://github.com/metabase/metabase/issues/10257

@flamber
Yeah, I’ll try looking up some similar drivers first to save me some work.

I’ll make sure to come back here should I open the request.
Should I also decide to experiment with Metabase’s source code and customize this behavior, I’ll also be sure to come back here.

Thanks again for your excellent help. Keep it up! :slight_smile: