On 18/08/2022 04:01, Mark Rotteveel wrote: > On 18-08-2022 04:02, Adriano dos Santos Fernandes wrote: >> How are client libraries (Jaybird, .NET Provider, Delphi ones) >> describing its named parameters to their users? >> >> I mean, given this SQL: >> >> select * >> from rdb$database >> where :param = 1 or :param = '2' >> >> We have here single name used in context with multiple types. >> >> I suppose you transform this to: >> >> select * >> from rdb$database >> where ? = 1 or ? = '2' >> >> Which will map to two Firebird parameters with different types. >> >> But for the user of the library, I suppose it's one parameter, correct? >> >> And what type (and the deduction rules) this parameter will be >> described as? > > JDBC doesn't define support for named parameters in > java.sql.PreparedStatement, only in java.sql.CallableStatement, which is > for calling stored procedures, and that support is optional, so Jaybird > doesn't have any support for named parameters. > > So, if Firebird is going to implement real named parameters, Jaybird is > probably not going to support them, and in that case I would really love > if this is controlled through a DPB item so when disabled, use of a > named parameter results in an error (e.g. "named parameters in DSQL are > not enabled" or something). Maybe I can then allow users aware of named > parameters to enable it explicitly to map it them themselves, for > example if something like `column1 = :param1 and column2 = :param2 and > colum3 = :param1` results in two parameters (param1 = position 1, and > param2 = position 2), and setting by position still works. > > The reason Jaybird probably is not going to support this, is because > most people don't use the JDBC API directly, but through things like > Hibernate, so adding vendor extensions to the JDBC API is pretty much > wasted effort because those libraries only use the JDBC API. I could add > such methods to the FirebirdPreparedStatement interface, but that would > then be a niche feature for people who do use JDBC, and are able to > unwrap to the FirebirdPreparedStatement interface (which is not always > possible when obtained from a connection pool). > > In the Java world, named parameters are usually emulated by layers like > Hibernate, or Spring's NamedParameterJdbcTemplate, which will map names > to positional parameters, and set the values of those positional > parameters appropriately. >
It's sad that JDBC does not report names in ParameterMetaData. There is not much to worry for Jaybird. And there should not be a setting to disable it, specially in this case. We don't put settings to disallow MERGE, UPDATE OR INSERT, etc. Layers that do emulations in client could continue doing it and pass positional parameters to Firebird. I just hope they do it well. In node-firebird-driver-native, even which a submitted PR, I prefer to avoid do it in the client. Named parameters will continue to work in positional way too. If you have expression ":A = 1 or :B = 2 or :A = 3 or :C = 4", order of them will be "A, B, C". Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
