Recapping some more thoughts exchanged with Sanne Grinovero:

We should limit ourselves to stores which natively support parameterized queries (MongoDB doesn't); While one could try to "emulate" it, there is the problem of how different parameter types should be represented in the query. If e.g. a parameter would be of type Date, it would have to be converted into the store's representation before replacing the parameter within the query and parsing it (one could also parse the query using a placeholder, but then we'd have no way to identify the corresponding part in the resulting query object, e.g. a DBObject in case of MongoDB).

For stores natively supporting parameters, we have the following options:

• Use the store's native parameter syntax, e.g. like so for Neo4j/Cypher:

@NamedNativeQuery(name = "MyQuery", query = "@MATCH (n) WHERE n.name = {name} RETURN n", resultClass = Foo.class )

We'd just pass the query and provided parameters to the dialect (and its driver) and let it deal with the parameter handling altogether. This would be specific per dialect but it feels quite natural for a user who uses a native syntax anyways. We couldn't really inject and functions or macros. Requires to disable the routines for parameter validation which are in place today as the engine wouldn't have any knowledge about parameters.

• Use an OGM-specific syntax to denote parameters:

@NamedNativeQuery(name = "MyQuery", query = "@MATCH (n) WHERE n.name = ${name} RETURN n", resultClass = Foo.class )

This requires a small bit of parsing as we'd need to replace the OGM syntax with the native one prior to submitting the query.

This would also allow to work with functions/macros handled by the engine which injects the result as parameter:

@NamedNativeQuery(name = "MyQuery", query = "@MATCH (n) WHERE n.date > ${fct:now()} RETURN n", resultClass = Foo.class )

In case a store's query syntax conflicts with the OGM parameter syntax, the former would have to be escaped so we know it's part of the query and no parameter. We'd have no knowledge about a specific query language's conventions for literals and comments, so parameters would also be resolved within the same (unlike today's behavior for native SQL queries in ORM).

• Use an OGM-specific syntax to denote parameters, not interpolating them in literals/comments:

@NamedNativeQuery(name = "MyQuery", query = "@MATCH (n) WHERE desc = 'Use ${name} as parameter' RETURN n", resultClass = Foo.class )

This would be more consistent with the current behavior for native SQL queries, but would require a specific parsing routine for each language, as literal and comment delimiters may differ.

I lean toward approach #2. WDYT?