Merging parameters from URL and property list in Jaybird 3

[Vasiliy Yashkov]

Hi!

There’s org.firebirdsql.jdbc.FBDriverPropertyManager#normalize(java.lang.String, java.util.Properties) method in Jaybird 2.2 driver, but Jaybird 3+ hasn't it. Instead, it's recommended to use org.firebirdsql.jdbc.FBDriverPropertyManager#normalize(java.util.Properties), but it does not accept URL to parse parameters. How I can merge URL parameters and existsing properties without custom parsing URL? I see org.firebirdsql.jdbc.FBDriver has mergeProperties(java.lang.String, java.util.Properties) method, but it's private.

[Mark Rotteveel]

In Jaybird 2.2 since 2.2.10, the url parameter is ignored and it's
identical in behaviour to the version in Jaybird 3. What is the use case
that you need to parse properties from the URL outside of the driver
itself? I could consider making it public, but having a good reason for
that would help me understand the use, and maybe provide a more suitable
alternative.

Mark

[Vasiliy Yashkov]

In our software some connection parameters are passed through URL string stored in xml file (with different number of parameters), and some parameters are dynamically added during a new logical connection. In addition, for logical connections, we use custom class FBSADataSource (not FBDriver) that does not accept connection URL to parse it. Anyway, we have two sources of parameters that need to be merged, so the normalize(java.lang.String, java.util.Properties) method is very useful to us. Some example:

        Properties properties = new Properties();

        // these parameters are dynamically changing
        properties.put("isc_dpb_user_name", userName);

        properties.put("isc_dpb_process_name", processName);

        properties.put("isc_dpb_process_id", processID);

        // this URL is taken from xml and the number of parameters may vary depending on system configuration
        // jdbc:firebirdsql:localhost:ncore.head.dev?lc_ctype=WIN1251&certificate=/opt/keys/ncore_cert.crt&multi_factor_auth=1&trusted_auth=1

        final Map<String, String> normalizedInfo = FBDriverPropertyManager.normalize(jdbcUrl, properties); // merge
        final GDSType type = GDSFactory.getTypeForProtocol(jdbcUrl);

        final FBSADataSource fbDataSource = new FBSADataSource(type); // implements DataSource, Serializable, Referenceable, FirebirdConnectionProperties, ConnectionEventListener
        fbDataSource.setDatabase(databaseUrl);
        for (Map.Entry<String, String> entry : normalizedInfo.entrySet())
            fbDataSource.setNonStandardProperty(entry.getKey(), entry.getValue());
        final Connection connection = fbDataSource.getConnection();

четверг, 25 июня 2020 г., 15:36:03 UTC+3 пользователь Mark Rotteveel написал:

[Mark Rotteveel]

Ok, I understand what you're doing. I would recommend to switch to using
pure property-based configuration (or key-value pairs in XML), instead
of this mix-form, but I understand that it might be hard to change your
existing API/implementation.

I'll take a more in-depth look this weekend, to see what I can do to
accommodate this.

Mark

On 2020-06-25 16:27, Vasiliy Yashkov wrote:
> In our software some connection parameters are passed through URL
> string stored in xml file (with different number of parameters), and
> some parameters are dynamically added during a new logical connection.
> In addition, for logical connections, we use custom class
> FBSADataSource (not FBDriver) that does not accept connection URL to
> parse it. Anyway, we have two sources of parameters that need to be
> merged, so the normalize(java.lang.String, java.util.Properties)
> method is very useful to us. Some example:
>
> Properties properties = new Properties();
>
> // these parameters are dynamically changing
> properties.put("isc_dpb_user_name", userName);
>
> properties.put("isc_dpb_process_name", processName);
>
> properties.put("isc_dpb_process_id", processID);
>

> _// this URL is taken from xml and the number of parameters
> may vary depending on system configuration_

[Mark Rotteveel]

On 25-06-2020 20:31, Mark Rotteveel wrote:
> Ok, I understand what you're doing. I would recommend to switch to using
> pure property-based configuration (or key-value pairs in XML), instead
> of this mix-form, but I understand that it might be hard to change your
> existing API/implementation.
>
> I'll take a more in-depth look this weekend, to see what I can do to
> accommodate this.

I think that the following is the least intrusive solution to this
problem: https://github.com/FirebirdSQL/jaybird/pull/31

It will add a `public static Map<String, String>
normalizeProperties(String jdbcUrl, Properties connectionProperties)` to
`FBDriver`.

I also considered defining this in the `FirebirdDriver` interface and as
an instance method in `FBDriver`, but my guess is that implementing it
as a static method is the simpler solution here.

Would this be an acceptable solution for you? If so, I can then add
tests and backport it to Jaybird 3 and 4 (I can also commit it to
Branch_2_2 if you want me to, although I won't release a Jaybird 2.2.16).

Mark
--
Mark Rotteveel

[Vasiliy Yashkov]

воскресенье, 28 июня 2020 г., 12:54:18 UTC+3 пользователь Mark Rotteveel написал:

I think that the following is the least intrusive solution to this
problem: https://github.com/FirebirdSQL/jaybird/pull/31

It will add a `public static Map<String, String>
normalizeProperties(String jdbcUrl, Properties connectionProperties)` to
`FBDriver`.  

 

Would this be an acceptable solution for you? If so, I can then add

tests and backport it to Jaybird 3 and 4 (I can also commit it to
Branch_2_2 if you want me to, although I won't release a Jaybird 2.2.16).

Yes, I think this is a good solution. 

We would like to see this solution in Jaybird 3 and 4. We refuse driver version 2.2.x, and I don’t think it is relevant to 2 version.

Vasiliy

 

[Mark Rotteveel]

Ok, I'll implement this shortly. The change will be released with
Jaybird 3.0.10 and 4.0.1 (and 5).

The method you were using in Jaybird 2.2, stopped doing what you
expected from it starting Jaybird 2.2.10. So, I though that if you are
still using (or supporting) versions based on Jaybird 2.2.10 or higher,
you might want to have this solution in 2.2 as well. But if you don't
need it, that is fine; it saves me work ;)

Mark
--
Mark Rotteveel

[Arioch The]

Does "static method" mean it is application-hglobal singleton?

Can this somehow limitation this intf for an application having several connections with different properties each, like DBWeaver ?

вс, 28 июн. 2020 г., 12:54 Mark Rotteveel <ma...@lawinegevaar.nl>:

--
You received this message because you are subscribed to the Google Groups "firebird-java" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-jav...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebird-java/9c2af066-503e-ab6d-07ac-27154420e396%40lawinegevaar.nl.

[Mark Rotteveel]

On 28-06-2020 15:09, Arioch The wrote:
> Does "static method" mean it is application-hglobal singleton?
>
> Can this somehow limitation this intf for an application having several
> connections with different properties each, like DBWeaver ?

It is a static **method**, which just means that you call it on a class,
instead of an object. The method itself changes no state, it is a pure
function that transforms its input of a JDBC url and a Properties object
into a new HashMap with the merged and normalized properties.

In essence, it just exposes what Jaybird is already doing internally
when creating a new connection.

So, no, there is no limitation or problem with connections with
different properties.

Mark
--
Mark Rotteveel

[Arioch The]

> It is a static **method**, which just means that you call it on a class,
> instead of an object.

...which exactly makes it app-global.
You can have several instances/objects, but the class is one and the same.

> The method itself changes no state, it is a pure
> function that transforms its input of a JDBC url and a Properties object
> into a new HashMap with the merged and normalized properties.

Oh, a pure function that only knows its parameters and no outer
context. Then sure, natural singleton it is.

I was thinking more like about non-static method which would take JDBC
url from a given connection object/instance.

Something like (in pseudocode)

/* creating connection object */

Conn.DatabaseURL = ".......";
Conn.AnotherOption = .....;
.....
Conn.NowAllOptionsSetOpenConnectionFinally();

In such a pattern getting map of option is naturally instance-defined metod.

But if in Jaybird, both JDBC and JPA, none of that kind is used and
URL only is ever passed as an argument to some .Open function - then
pure static function is the only thing that makes sense.

That, of course, i